Summary: I have seemingly hit a limitation in Figma when trying to make the columns behave akin to a CSS grid system. I would like to know if I have misunderstood Figma's built in capabilities, if there is a plug-in that solves the problem, if I have to create one Figma frame per CSS breakpoint (undesirable), or if there are other solutions.
Background: As an interaction/ UX designer, I would like to specify the responsiveness of a web based application, so that the front end developers know how the interface should appear at all browser widths. They implement in a CSS-based grid system similar to Bootstrap
So far, I failed in achieving what I want, and the most knowledgeable UX'ers in the company think I have hit a limitation in Figma's capabilities, but they are not certain.
Basically, what I want is this basic responsiveness, but column based. But as shown in this video, none of my experiments work.
I wonder if it boils down to this: If a Figma child element has:
horisontal constraint set to “Scale” and
vertical constraint set to “Hug contents”
Then the parent element cannot have:
vertical constraint set to “Hug contents”
Is this is a known limitation in Figma? If yes, are there plugins that solve this problem, or is it outside Figma's scope to offer this type of alignment with CSS-based grid systems? Obviously, it would be very beneficial if the solution also supports breakpoints.
P.S. I have asked which SE site that was most suitable for this question, and SO was the suggested site. The question was closed on UX.SE.
No, according to an answer on Figma's own forum, Figma's columns cannot behave akin to a CSS grid system, even though “several threads [have] requested [this] evolution”.
we're maintaining some Qt applications which are running on Linux and Windows desktops. Now, we want to make the applications more attractive by adding customized forms and reports for each customer or at least groups of customers. There may be 10 or more different versions needed.
As we come from Qt, we are wondering how to manage so many configurations and if there already is a framework/development system that would help us here. We were looking at QML/Qt Quick, WT Toolkit or even NC Reports for the reporting part.
Managing configurations and deriving different versions from a base is not a feature which is discussed or promoted.
There should be a clean distinction between Display and Application Logic (Model/View)
Nice would be a textual GUI description, which enables us to release changes in forms or reports without the need to reinstall the whole applications (like QML seems to have that)
Also nice would be a kind of report generator, that helps to create forms and reports for new customers without the need to code them (and so releases our core developers from boring work)
Has somebody experience with such kind of customer based configurations? It would be nice to have a hint what's the best way to do this in the Qt surrounding.
I know comparisons like http://qt-project.org/doc/qt-5.1/qtdoc/topics-ui.html#comparison, but the specific questions that I have are not mentioned.
best regards
I guess you need to differentiate applications in three aspects:
1. appearance - if the application only differs in button color, icon image and background themes, qt's style sheet is light and convenient, you can choose to deploy different qss file and load different ones without recoding. if the variance among customers concerns layouts or available widgets (some has buttons, some use combo boxes, .etc), style sheet cannot meet the requirement, QML seems promising in such case.
business logic - i'm not sure how "generating reports" differs for different customers, if the reports need to be printed, or saved as document, i don't think qt provides good toolkit (QXXXDocument is not suitable to generate / display large amount of document), html? maybe. And i agree with #hyde that loading different plugins or dynamic libraries can solve this.
What I learnt from 8 month qt:
Model/View Architecture is there, for example a tree view that we fill with voyage data. the data is gatheres from several db tables, so we have a good logical distinction.
We hadn't the time to work us into qml, so we stuck with qt designer. It's quite easy, so we're fine with that. Delivering changes in customer forms without recompile will be a feature for a bigger future rework.
Same with report generators...
Every time I try to use the D Forms Library, I run across the fact that it has no TableLayoutPanel -- which makes it practically impossible for me to make a good GUI.
Is there any TableLayoutPanel implementation out there for DFL?
How do people usually use this library without it?
Edit:
A link to another program that uses DFL would be a great bonus for an answer. :)
Posting as an answer because length exceeds comment length limit.
I downvoted your question because it is formulated with elements of flamebait. I would guess that your previous experience with GUI libraries was mostly with libraries supporting box layouts, such as Qt. The Win32 GUI API itself does not provide any primitives for creating box layouts - it uses absolute coordinates through and through. This remains unchanged in many OO libraries that build on top of the API, such as MFC. Some libraries, like VCL, have optional primitives for creating box layouts (panels with alignment and auto-size) - but in the end, all control repositioning has to be done by the application or the GUI framework, so something like this would need to be implemented in DFL from scratch.
So, to answer your questions:
Is there any TableLayoutPanel implementation out there for DFL?
Probably not.
How do people usually use this library without it?
They draw the controls on the form with a mouse, using Entice Designer. (The same is true for MFC/Visual Studio, VCL/Delphi IDE, etc.)
Reply to comment:
how do I put things in a table layout (e.g. two side-by-side, and one below)?
I understand that you'd like to have a fixed-height panel at the bottom, and split the remaining space into two areas which both remain half the form's width when the form is resized.
In Entice Designer, place a Panel, set its dock to BOTTOM. Set its height appropriately.
Place a second panel, set its dock to RIGHT.
In your form's code, add the following method:
protected override void onResize(EventArgs ea)
{
super.onResize(ea);
panel2.width = this.clientRectangle.width / 2;
}
As you can see, it can quickly get messy to get a more complicated "rubber table". I wouldn't bother, or if I really needed complex dynamic layouts, would look for another library.
Or are you saying that's a bad idea in the first place?
Definitely not my point - the advantages of semantic layouts that don't require using an IDE to build are clearly visible. It's just that due to their Win32 API roots, Windows GUI libraries rarely provide good means to build them. Of course, their absence doesn't make building GUIs impossible or even hard - people simply usually go with fixed-size forms, etc. (This is clearly visible to end users switching from Windows to KDE - most KDE dialogs are resizable, while Windows' aren't.)
in lack of a table layout you can use the location and size properties to position stuff on the board (and maybe even implement your own table layout)
you can use the entice designer to make the gui and build further on the generated source
Now that I'm near my code, there are two ways to manage layout. As mentioned by ratchet there is absolute positions and also docking. Docking places the item in 5 possible locations. The Top, Bottom, Left, Right, or Center (fill). You can then place a panel in one of these which can itself contain elements that are docked within it. You assign the docking value to the dock property.
Entice Designer is written with DFL.
I would like to start coding a gtk theme engine, but i'm wondering where i can find some documentation, if any exists.
I know how to have look at someone else engine's code, examples, or torture tests and widget factories etc.., what i want instead is any documentation type, design, references, examples or tutorials possibly from reliable sources such as the Gnome foundation or the like.
You know, when coding for the Win32 platform one can pinpoint reliable references on the subject by following the MSDN and then read a variety of other sources to see how the problem has been tackled, if any.
So, where to find an authoritative, reliable and possibly complete source of documentation about GTK theme engine development? Is there any for real?
Later added:
Also, how to debug such an engine? What's the most sane and painless way to perform testing and debugging on such a delicate os' ui component?
Well, you can look for instance at the source for the gtk smooth engine in Ubuntu most of which is in one fairly enormous C file smooth_gtk2_drawing.c. I don't know if that's an especially good example, but probably finding whichever looks simplest or most actively maintained would be a good idea.
A theme engine is typically used to change the shape of widgets among other things. If you're just trying to change the color scheme and so on, you just need to create a theme.
Just like the theme engines, theres not a whole lot of documentation when it comes to creating a theme either. However, there are a ton of examples at http://www.gnome-look.org
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm spending these holidays learning to write Qt applications. I was reading about Qt Designer just a few hours ago, which made me wonder : what do people writing real world applications in Qt use to design their GUIs? In fact, how do people design GUIs in general?
I, for one, found that writing the code by hand was conceptually simpler than using Qt Designer, although for complex GUIs Designer might make sense. Large GUIs might be possible using Designer, but with time they might become very difficult to manage as complexity increases (this is just my opinion). I also downloaded the AmaroK source code to take a peek at what those guys were doing, and found many calls to addWidget() and friends, but none of those XML files created by Designer (aside: AmaroK has to be my favorite application ever on any platform).
What, then, is the "right" way to create a GUI? Designer or code? Let us, for this discussion, consider the following types of GUIs :
Simple dialogs that just need to take input, show some result and exit. Let's assume an application that takes a YouTube URL and downloads the video to the user's hard disk. The sort of applications a newbie is likely to start out with.
Intermediate level GUIs like, say, a sticky notes editor with a few toolbar/menu items. Let's take xPad for example (http://getxpad.com/). I'd say most applications falling in the category of "utilities".
Very complex GUIs, like AmaroK or OpenOffice. You know 'em when you see 'em because they make your eyes bleed.
Our experience with Designer started in Qt3.
Qt3
At that point, Designer was useful mainly to generate code that you would then compile into your application. We started using for that purpose but with all generated code, once you edit it, you can no longer go back and regenerate it without losing your edits. We ended up just taking the generated code and doing everything by hand henceforth.
Qt4
Qt4 has improved on Designer significantly. No longer does it only generate code, but you can dynamically load in your Designer files (in xml) and dynamically connect them to the running objects in your program -- no generated code however, you do have to name the items in Designer and stick with the names to not break your code.
My assessment is that it's nowhere near as useful as Interface Builder on Mac OS X, but at this point, I could see using the Designer files directly in a program.
We haven't moved back to Designer since Qt3, but still use it to prototype, and debug layouts.
For your problems:
You could probably get away with using the standard dialogs that Qt offers.
QInputDialog or if you subclass QDialog, make sure to use QButtonDialogBox
to make sure your buttons have the proper platform-layout.
You could probably do something more limited like xPad with limited Designer functionality.
I wouldn't think you could write something like OpenOffice solely with Designer but maybe that's not the point.
I'd use Designer as another tool, just like your text editor. Once you find the limitations, try a different tool for that new problem. I totally agree with Steve S that one advantage of Designer is that someone else who's not a programmer can do the layout.
In my experience with Qt Designer and other toolkits/UI-tools:
UI tools speed up the work.
UI tools make it easier to tweak the layout later.
UI tools make it easier/possible for non-programmers to work on the UI design.
Complexity can often be dealt with in a UI tool by breaking the design into multiple UI files. Include small logical groups of components in each file and treat each group as a single widget that is used to build the complete UI. Qt Designer's concept of promoted widgets can help with this.
I haven't found that the scale of the project makes any difference. Your experience may vary.
The files created with UI tools (I guess you could write them by hand if you really wanted to) can often be dynamically loaded at run-time (Qt and GTK+ both provide this feature). This means that you can make layout changes and test them without recompiling.
Ultimately, I think both raw code and UI tools can be effective. It probably depends a lot on the environment, the toolkit/UI-tool, and of course personal preference. I like UI tools because they get me up and running fast and allow easy changes later.
The organisation I work for has ported its GUI application to Qt several years ago.
I think there are several aspects that are worth mentioning:
Working with Qt Designer, at least at that point, was not a realistic option: there were too many features that couldn't be done with Qt Designer;
Conventions and structure that had to be preserved prevented the use of Qt Designer;
Once you've started without Designer, it is probably difficult to return to it;
the most important aspect, though, was that the programmers were very much used to programming using vi or emacs, rather than using a GUI IDE.
My own experience, which goes back approx. 4 years, using Qt3.3, is that dynamic behavior in dialogs was not possible to realise in Designer.
Just to say I've written and maintained complex GUIs in Qt without using Qt Designer -- not because I don't like Qt Designer, but because I never got around to working that way.
It's partly a matter of style and where you're coming from: when I started on Qt, I'd had horrible experiences of Dreamweaver and Frontpage and other visual HTML tools,and far preferred writing code with HomeSite and resorting to Photoshop for tricky layout problems.
There's a danger with visual code IDEs that you try to keep within the visual tools, but end up having to tweak code as well -- in ways that aren't well understood.
Learning iPhone development, for example, I've found it frustrating to hit 'magic' visual stuff ('drag from the empty circle in the Connections inspector to the object in the Interface Builder window...') that would be simpler (for me) to understand in plain old code.
Good luck with Qt -- it's a great toolkit, however you use it, and Qt Creator looks like being a great IDE.
I'd add that one of the reasons for using graphical designer was the lack of layout managers in Win32, for instance. Only absolute positioning was possible, and doing that by hand would have just sucked.
Since I switched from Delphi to Java for GUI apps (back in 2002), I've never used designers any more. I like layout managers much more. And yeah, you get boilerplate code, but moving objects on a UI designer may take as much time as changing the boilerplate. Plus, I would be stuck with a slow IDE; that's for the Java/C# case, OK, while for Qt (especially Qt4) it doesn't apply. For Qt3, I wonder why one should edit the generated code - wasn't it possible to add code in other files? For which reason?
About the discussed cases:
1) Hand Coded GUI is likely faster to write, at least if you know your libraries. If you're a newbie and you don't know them, you may save time and learn less with a designer, since you don't need to learn the APIs you use. But "learn less" is the key factor, so in both cases I'd say Hand Coded GUI.
2) Menu bars are quite annoying to write code for. Also, think to details like accelerators and so on. Still, it depends on what you're used to. After some time, it may be faster to type that boilerplate than to point-and-click into designer to fix all those properties, but just if you can really type like into a typewriter (like those admins for which typing Unix commands is faster than using any GUI).
3) I'd extend the answer for case #2 to this one. Note that, for Win32 platforms, it may be possible that using designers which generate Win32 resources might be faster to load (no idea about that).
However, I'd like to mention a potential problem with using Qt Designer there. Real world case: it took some seconds (say 10) to load a complex Java dialog (the Preferences dialog box for a programmer's text editor) with a lot of options. The correct fix would have been to load each of the tabs only when the programmer wanted to see them (I realized that after), by adding a separate method to each preference set to build its GUI.
If you design all the tabs and the tab switcher together with a designer, can you do that as easily? I guess there might be a similar example where a hand coded GUI gives you more flexibility, and in such a big app, you're likely to need that, even if just for optimization purposes.
One of the main benefits of using designer to create GUIs is that other programmers can change or maintain forms and widgets easily without the need to delve in to a complex code.
Its strange that you're saying the writing code is simpler than manipulating objects in a graphical environment. It's a no-brainer.
The designer is there to make your life easier and in the long term it makes your code more maintainable. It's easier looking in the designer to see what the your UI looks like then reading the code and trying to imagine what it might look like.
With current Qt you can do almost everything from within the designer and the very few things you can't do, you can fix with very few lines of code in the constructor.
Take for instance the simplest example - adding a signal-slot connection. Using the designer it's as simple as a double click. Without the designer you need to go lookup the correct signature of the signal, edit the .h file and then edit write your code in the .cpp file. The designer allows you to be above these details and focus on what really matters - the functionality of your application.
I like to first turn to the designer to develop GUI widgets. As mentioned in the other posts, its faster. You also get immediate feedback to see if it "looks right" and isn't confusing to the user. The designer is a major reason I choose Qt over other toolkits.
I mostly use the designer to make the one-off dialogs.
Having said that, I do the main window and any complex widgets by hand.
I think this is the way Trolltech intended. QFormLayout is a class they provide to easily programatically create an input dialog.
By the way, the designer in Qt 4 is not an IDE like the one they had in Qt 3. It's just an editor for editing .ui files. I like it that way. The new cross platform IDE is going to be called Qt Creator.
It's an old post but I would advise you to look at Clementine - a music player which (I think) derives from Amarok. They use Qt4 and from what I can see there is a ui folder in the src folder of the project. In the ui folder as one might expect they have all sorts of .ui files. If you compile and start Clementine you will see that the GUI is fairly complex and quite nice.
For me, it depends how much logic is encapsulated in the widget/GUI. If it's just about simple forms, I prefer to use QtDesigner.
If it contains complex checks or interaction, I tend to program it.
We're using the Qt Designer if anyone needs to create a Gui.
The thing is to create just little Widgets for certain tasks (like you would do in a class-design) and then get them together into a "parent-gui".
This way your widgets are highly reusable and could be used for Guis in a modular way. You just have to specify which signals each Widget is sending and which slots they provide.
We additionally are creating .ui-Files which than could be generated during build-process. Until now there was no need to edit those files by hand.
Build different parts of your UI
in different .ui files using QtDesigner,
then bring them together (and add complications) in code.
There are things you can't do in Qt Designer, you can only do in code,
so Qt Designer is just one (great) part of the tool chain.