I am working on a C/GTK+3 project right now. I have a little experience with front end but mostly only with Android. Even then that was VERY LITTLE experience.
I notice that in the C code I place objects and set properties (like if a textview is editable etc). I also have been able to connect a .ui XML file to my program with the builder functions.
I am wondering how the XML file gets linked to the C code defining the interface. Does it match by structure, by the name or ID properties? Why are properties like "visible" and "editable" present in both the C code and the XML? Do you need the XML file? Do you need to specify the properties in both the XML file and the C code or just one? Will I ever completely understand front end development?
There's two ways of constructing a user interface:
You write the code for it.
You write a file that describes the user interface, and have the user interface built for you at runtime.
If you write the code yourself, everytime you want to move widgets around, you have to modify your code, that you'll need to compile. That is doable for a small UI, and is what is done in most tutorials.
If you use ui files, then you use the Glade application to design your UI graphically, and it will write the UI files for you. This helps in splitting responsabilities too: you may have design people taking care of the UI, and let developpers focus on the behavior. Even without that, you'll be able to design a UI faster with an editor like Glade than by coding it by hand. Think you skip all the compile/debug cycles.
In your ui file, if you name a wigdet "bob", you'll be able to get it in your code by passing its name to gtk_builder_get_object. GtkBuilder takes care of the construction and the memory, so don't destroy the widgets it creates if you need to display them again, and hide them instead.
You have examples of use of UI files in the GTK documentation:
https://developer.gnome.org/gtk3/stable/ch01s04.html#id-1.2.3.12.5
Related
Fairly new to WPF.
I'm tasked with converting our application with about ten different windows into a single-window, multi-tabbed application. I'd like your input on the most effective way of doing this.
I suppose I could do this the most-straightforward way -- copying and pasting a ton of code into the main XAML file. I imagine I'd end up with a gigantic file though, and would like to avoid that.
I should mention that the contents of each tab will be substantially different from each other.
There must be some element of WPF that enables this that I just haven't been able to find. Really appreciate any input.
In XAML there are user controls which you can use. That way, you could use one user-control per tab-content and let the main window only contain the tabview and tabitems and some minor logic code.
To achieve that, you can simply copy-paste most of your current window-code in one user control per window. The code base could remain almost the same (if there are no interactions between the windows at least).
There are quite many resources out there containing further details on user controls like this code-project article (a bit old, but the majority of its contents will still apply) or that MSDN one.
I am building a wpf user control to provide navigation facilities for database records.
The control is provided with a set of default images (as illustrated above) which the end user can change is they so wish. In addition the end user can choose to dispense with images altogether. In the event that they select that option (for either one or all of the buttons that comprise the control) I have provided some default fallback text.
This text can also be overwritten by the end user if they so wish, but the default text at least provides them with some basic text that essentially conveys what the button does and saves them having to add text every time they use the control (default tooltip text is also provided).
Now if you happen to speak English, or your intended target audience is English this should work, but it doesn't really cater as is for languages other than English. This I would now like to change.
What reading I've done on the subject of multi-lingual resources and wpf seems to assume that one is talking about the overall application rather than a standalone user control that might be used in different language environments.
I had a talk with a creator of controls who said that making this multilingual would probably involve building several copies of the control for each intended language.
In the light of this I have two questions. Was the gentleman I spoke to correct, should I in fact build multiple copies of this for each language, of is there a way to have multi-language resources within the same copy of the user control?
If the latter is possible what is the correct way to go about achieving this. We will be dealing in total with default texts for eleven buttons (which I will need to be able to refer to in code within the control incidentally) and default texts for thirteen tooltips (which again will need to be able to be referred to within the code of the control).
Take a look on WPF localization extension.
Here's a pretty good documentation for it: link.
You can define your controls' localizable properties, which store their localized values in the satellite resource assemblies.
In your xaml code, define the localized properties with xaml extensions syntax:
<Button Content="{lex:Loc Test}" />
Then, create resource files for each culture your application will support and give them the same name as the main assembly plus the general or specific culture code (e.g. en-US, de, de-AT, ...) before the .resx ending yielding: AssemblyName.CultureCode.resx.
Now, populate the resource files with your localized properties key/value pairs and build the project.
You're done!
I'm fairly new to GTK, and am messing around with my first "serious" GTK (gtk+-3) app. I'd like to draw on the wisdom of others' experience about when it's suitable to define a new GTK class, or just use a "vanilla" GTK classes, and implement behaviour via signal handlers.
I've come across two examples so far:
Custom Widgets
I'm creating a new widget: basically a GtkDrawingArea, which I use to display some data. I had originally assumed that the best way to implement this would be to subclass GtkDrawingArea, using G_DEFINE_TYPE, and provide my own draw callback:
static void mywidget_class_init(MyWidgetClass *klass)
{
GTK_WIDGET_CLASS(klass)->draw = mywidget_draw;
}
However, it looks like I could implement exactly the same functionality without defining a new type, by just creating a vanilla GtkDrawingArea, and hooking up the appropriate signals during initialisation.
[My custom widget will eventually provide more than just the draw callback, as it needs to be interactive, but that comes later...]
Application Windows
My application consists of a few different windows, which currently are vanilla GtkWindows:
struct myapp_somewindow {
struct myapp *app;
GtkWindow *window;
GtkWidget *some_label_that_is_updated;
/*... other window-specific fields */
}
When the myapp_somewindow struct is initialised, I create the GtkWindow with gtk_window_new(), and initialise the widgets/layouts/etc, and connect the signals. [I'll probably be using .ui files for the more complex cases eventually, but the windows are simple enough for now.]
This could be done my defining a new subclass of GtkWindow, but I'm not certain when the code overhead of defining the new class becomes worthwhile.
I'm aware that there's probably no strict rules for which approach to take, but are there any general guidelines to use when making these design decisions? Are there any major pitfalls of either approach?
I've worked on a fair few projects using GTK+ and Clutter and i've always promoted heavy use of subclassing of generic widgets / actors to more specific ones.
By convention with GObject you create a new file for each class and thus if you pull in the behaviour and state mechanics associated with your widget into a subclass you will pull that code into a separate file. This helps make it easier to structure your code and helps when someone else wants to come along and read it.
The subclassing strategy also helps you enforce encapsulation as a good practice on your code base. If your widgets and their associated state and logic are well encapsulated then that can help with reuse.
A good example of a project where this subclassing strategy has been used is tasks, and in particular it's internal helper library: http://git.gnome.org/browse/tasks/tree/libkoto This meant that when we wanted to port the application to a new platform or provide a different view on the data it was quite easy to just glue the existing widgets and tree models together in a different way.
If you want to use C and you find subclassing a bit tedious then you can try this tool: http://git.gnome.org/browse/turbine/ to help automate the creation of your subclasses.
I would use the guideline of defining a new class when you need to save some state for the widget. Otherwise, you'll end up creating custom structures holding that state to pass as user data to the signal handlers, making your code more complicated and creating more opportunities for memory leaks.
That would suggest that for your second use case, application windows, you should always define a new class.
One reason to do it this way is that your widget might start out simple, with behavior that you can implement purely with signal handlers, but later might become more complicated. For example, suppose you want to add a backing store to your drawing area. The "perceived cost" of refactoring your simple widget into a class is high, whereas it'll make your code much cleaner than working around it.
Another advantage is that classes can have properties. You can bind these properties to other classes' properties or to GSettings keys, which is a really powerful mechanism and can make your code really simple.
If you don't like all the class boilerplate, consider programming in Vala.
I searched and Googled first, thinking surely someone must have asked this before, but I sure can't find a good description of this problem.
I have six or eight similar C# .NET 2.0 WinForms applications built with the fairly common model of a main application window with several GUI data fields plus several modal dialogs for further data collection. Many of the data fields (especially TextBoxes) have identical data validation routines. I'm writing the same xxx_Validating() routines over and over, which in the simplest case only capitalize the first character of the entered text (if any) and redisplay the result. I have another one for ZIP Code fields that takes the first 3 digits of a 5-digit US postal ZIP Code and returns the corresponding State, using a 1000-member string array. Simple stuff. There are a few others; here's an example:
public void CapFirstCharTextBox_Validating(object sender, CancelEventArgs e)
{
string strValue = ((TextBox)sender).Text.Trim();
if (strValue.Length >= 1) {
if (char.IsLower(strValue[0])) {
strValue = strValue.Substring(0, 1).ToUpper() + strValue.Substring(1);
((TextBox)sender).Text = strValue; // fires (whatever sender)_TextChanged()
}
}
}
Again this is part of a half-dozen or so such "utility" routines. I've only got one set of these per dialog box class, and all the various TextBoxes in that dialog which need this have their Validating event pointing to the same method. So it's not like I've got 20 of these in a given source file (one for each TextBox) or anything; there's only one for the whole dialog class.
Problem is, the whole set of these exists in every source file where I need them. That's one set for the main window and more for each pop-up dialog box -- and that's too many. I understand modal dialog box classes can't communicate with each other, and making all this stuff global is elusive at best and a big "no-no" at worst.
I have successfully tried passing a reference to "FormMain" (where one copy of these routines exist) to the various dialog constructors, and then calling these validation routines with that from their own validation handlers. It works but feels awfully clunky and certainly not like the best approach.
So, how would I (or would I want to) rearrange the project and organize the code better to have only a single instance of these kinds of things? How would I wire up a global "utility" class of such methods such that I can get to it from the main form's code and from that of a bunch of pop-up modal dialog boxes as well?
I'd like to maintain just one executable with no additional .DLLs if possible (these are all one-project-per-solution, by the way), and if practical I'd like to further be able to share that common code across multiple solutions.
I think the answer will include writing new assemblies, using different namespaces (currently all my code in a given project is contained in the same namespace), and maybe separating this stuff out into its own project in the same solution file.
Is it possible?
You can share code across solutions by keeping the code in one place and adding a link to the file in each solution.
To add a link: right click the project (or folder) you want to add the code to, then select "Add existing item", browse for the file, when found click the down arrow on the button and pick Link to.
This way the projects that link to the file will share the same code.
BTW: take care when using a source control system that doesn't know how to handle these links.
So far, I've been able to create a window in C, and add a button and edit box to that window. But, where can I find an exhaustive list of the system classes for all the form controls? I can't remember where I found BUTTON and EDIT--is there a LABEL? LISTBOX? CHECKBOX? COMBOBOX? etc.
Then, how would I use those built in windows functions...I think they're called common controls? Like open a file, save as, print, etc.
You will go insane if you try to write raw Win32 code with C. If you can use C++, I highly suggest using Qt, if not, use Gtk.
Here you are: they are on MSDN.
But I agree with Zifre that you better use a gui-framework for stuff like this.
There are more like these, e.g. MFC or WTL.
Some people like things pure
stromcode zetcode forgers and heck if you're really feeling crazy, win32 in assembly
For the open dialogs and so on you want the Common Dialogs section -- http://msdn.microsoft.com/en-us/library/ms645524(VS.85).aspx.
Whilst on the subject of Win32, if you're using the file dialogs and therefore file names you may also find the shell functions (http://msdn.microsoft.com/en-us/library/bb776426(VS.85).aspx) handy -- in particular, the PathXXX ones. I wish I'd known about these when I was getting started.