Working like a charm!
Thanks my friend.
If it’s OK, a few follow up questions:
Will this effect both phone and desktop views? On phone view there’s actually no problem and it utilizes 100% of the screen anyway. I just don’t want to mess with it.
I’m not sure if this is from the Pages world, but how can we play/design elements side by side? For example, when we select a tab design to be “calendar” or “List” we get a screen with two parts. Can we design something similar inside a Details tab, moving some components to one part of the screen, and other components to the other side?
Perhaps the same question as no.2 above: I’m looking for a way to display paragraphs with many lines, coming from a list relation.
you gonna have to go over each element and fix it with CSS, especially inline lists…
CSS is hard to apply, that’s why is not supported by Glide, it takes a long time to make it work on all devices… i played with my Code BOOK CSS for over 2 weeks until I got it right.
Also keep in mind that sometimes it takes few refresh clicks for CSS to start working in live App
Yeah, I tried that but still no luck. I’ll keep digging. One thing I noticed is that when opening the developer toolbox (F12), the list width is actually “expanding” to full screen. This is without me changing anything in the CSS, or anything else. When closing the toolbox, list goes back to what seems to be 50% width.
I hope this will allow you to direct me towards a solution.
Because depending on how you have developer mode set up, it may be either displaying side by side with the app, making your app screen smaller to fit the side by side view, or developer mode is configured to display as a different device resolution instead of your normal desktop resolution. Glide apps are configured in a way that makes them dynamic across a wide variety of devices and resolutions, so they may reflow as needed.
I’m sure glide limits width to some degree, so you don’t have an unpleasant experience with stretching…especially if you have a super wide screen. Keep in mind that while apps will work on a desktop size screen, they are still apps that are intended for smaller devices. Glide’s code is optimized to to set screen and element sizes and locations based on screen resolution. And, with tablet/desktop mode, whenever the resolution becomes large enough, elements will reflow, and as such, list style screens will become two column displays and detail style screens will become centered. Apps just aren’t designed to be full scale desktop optimized views. That’s where pages come in. Pages are designed to fit better on larger screens.
Whenever you manipulate and override Glide’s stylesheets with manual CSS, you have to make sure that it’s compatible across a wide variety of devices and device resolutions. It’s a whole lot of trial and error, especially if you are not familiar with how CSS works. Really, what we are doing is performing a hack to override the set styles that glide established. Rather than initially setting the CSS, we are manipulating existing CSS to do something different. For these reasons, I tend to avoid giving CSS advise, because it’s best to understand what you are doing instead of just plugging in some code that you don’t understand, or that hasn’t been thoroughly tested across multiple devices and scenarios.
Thanks for this detailed input.
It’s set up to display at the bottom, leaving the screen width exactly the same as it is without dev mode. But yeah, as you say, it does change the resolution to some extent I assume, causing it to reflow. However, this does not explain why dev mode is “fixing” RTL issues. For example, in a “Basic Table” component, it’ll flip the columns, making it look as native RTL. Exiting dev mode flips back everything.
This is purely a guess, but based on past discussions that I’ve seen regarding RTL, I believe a lot of people have used unstable class names to achieve RTL since so many design elements have to be changed and many classes have a dynamically generated class name. When unstable class names are used, those class names can be different for different devices such as iOS or Android. On top of that, when an app reflows to fill a desktop/tablet format, I’m assuming that different class names and CSS stylesheets are used, which make the screen elements more suitable for tablet/desktop mode instead of the standard app mode. You would have to view the source, choose a particular element on the screen, and observe if the class name changes when viewing with a small app sized resolution vs a large desktop resolution. In a perfect world, glide would have stable class names in their CSS and DOM structure, but I’m not sure if they have much control over that based on how their software constructs the screens. Also, it would be ideal if they supported RTL natively, but I have no idea if and when they plan to allow for that. Again, we are trying to override existing CSS, and if different devices and screen resolutions cause different CSS to be used, then you have to plan accordingly to add manual CSS to account for all of those different scenarios.