After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 695457 - Use a .ui file for the main window
Use a .ui file for the main window
Status: RESOLVED FIXED
Product: gnome-weather
Classification: Applications
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: GNOME Weather Maintainer(s)
GNOME Weather Maintainer(s)
: 695508 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-03-08 18:35 UTC by Paolo Borelli
Modified: 2013-03-11 20:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Use a .ui file for the main window (6.39 KB, patch)
2013-03-08 18:36 UTC, Paolo Borelli
none Details | Review
Use the ui file for the New Location dialog (2.83 KB, patch)
2013-03-08 20:27 UTC, Paolo Borelli
none Details | Review

Description Paolo Borelli 2013-03-08 18:35:58 UTC
I would like to move as much as possible in the ui file, for instance the gdstack and the new location dialog, but this is a start to see if you agree. The patch is on top of the one for the "new" action, though unrelated.
Comment 1 Paolo Borelli 2013-03-08 18:36:00 UTC
Created attachment 238390 [details] [review]
Use a .ui file for the main window

This starts using a ui file for the toolbar an its buttons.
Comment 2 Paolo Borelli 2013-03-08 20:27:45 UTC
Created attachment 238408 [details] [review]
Use the ui file for the New Location dialog

Also rework the dialog slightly (a proper label, larger entry etc)
Comment 3 Giovanni Campagna 2013-03-08 21:36:50 UTC
Uhm... did you use Glade to edit these two?
Because in general I don't see the value of keeping hard to understand XML files, when you then have the same amount of JS code (considering the number of lines). Also considering that Glade does not know about GWeather or Gd, and last I tried it would complain and destroy those widgets.
Comment 4 Paolo Borelli 2013-03-08 22:52:10 UTC
I made those files manually transplanting them from clocks.
Glade is a pain, we all know that :)
But the more we use it and the higher the chance it will get fixed: I think new apps should set a good example

That said, I personally think that moving as much as possible to glade files is a good policy for the following reasons:

 - after 10+ years of gtk I can assure you that pack widgets and setting properties gets old. :) For instance doing the simple New Location dialog above requires a lot of boiler plate to set padding and borders etc

 - ui can be reworked and rearranged without touching the code as long as the widget keep the same name

 - designers can easily work on glade files: eg. I can imagine someone tweaking the New Location dialog above, changing the label or the padding etc: such changes can be easily integrated, even in the worst case, cut&pasting manually in the ui file is better than translating to js

 - it is less code in the actual logic of the app: even if the net count of lines is higher due to the verbosity of xml, it cuts boring widget management out of the way from the code you actually have to read and debug


With regard to Gd and Gweather note that it is relatively easy to create "catalog" files to have the widgets available in glade and for gd it will be done anyway when these widgets are moved to gtk. For Gweather it is more problematic because GweatherEntry api is not friendly and that's something that I was hoping to propose you to fix in the next cycle.
Comment 5 Giovanni Campagna 2013-03-09 14:08:55 UTC
I disagree that hand-editing XML files is better than hand-editing JS. Even properties are more verbose.

This said, I started a wip/gjs-experiments branch which makes a better use of GtkBuilder (with signals and exposed objects).
I'd like a comment from you (in particular on the 'javascript:' snippet idea)

Also, two implementation comments:
- Don't use mix objects for different windows in the same UI file, it causes GtkBuilder to build them unnecessarily.
- No space before open parentheses.
Comment 6 Paolo Borelli 2013-03-09 16:36:06 UTC
(In reply to comment #5)
> I disagree that hand-editing XML files is better than hand-editing JS. Even
> properties are more verbose.

Do not get me wrong, I agree that hand-editing XML sucks :)
But at least you usually do not touch them often and it gets the boring widgetry out of the way from code you have to read and debug every day.


> This said, I started a wip/gjs-experiments branch which makes a better use of
> GtkBuilder (with signals and exposed objects).
> I'd like a comment from you (in particular on the 'javascript:' snippet idea)

To be honest I do not like the snippet idea very much. As a matter of fact I think having signals in ui files is a practice that should be discouraged also in C. It makes following the flow of the program harder since you now need to look at both the js and the ui file to understand the logic, while my main goal of using ui file is to move widget structure out of the way so that the actual logic is easier to read and debug.

I think we should learn from the web in this case: unobtrusive javascript moves in the opposite direction, it avoids the use of "onclick" attributes etc and uses the html for the structure, while program logic is done with js for instance with $('#mybutton).click(function () {...}) which is somewhat equvalent to our "let b = builder.get('button'); b.connect('clicked', ...)"


> 
> Also, two implementation comments:
> - Don't use mix objects for different windows in the same UI file, it causes
> GtkBuilder to build them unnecessarily.

Yeah, we can split the new location dialog in a separate .ui file if that's what you prefer or we can use gtk_builder_add_objects_from_resource to build only the specified objects. I did not bother since the overhead is negligible, but I agree it is better.

> - No space before open parentheses.

Yeah, that's what happens when switching between C/vala/js/python each one with its code style :-)
I really wish I could run jslint on gjs programs...
Comment 7 Giovanni Campagna 2013-03-09 17:17:31 UTC
*** Bug 695508 has been marked as a duplicate of this bug. ***
Comment 8 Giovanni Campagna 2013-03-11 15:28:11 UTC
Ok, let's clean this up.
I see your point on signals. While there is a value in handling signals transparently in GtkBuilder in Gjs (after all, it is nice that you double click a button in Visual Studio and immediately start typing, and to do the same in Glade you need signal definitions), this is not required for us.
So you can go ahead, rewrite the UI files to have two different ones for the two dialogs, fix the indent and merge straight away to master and gnome-3-8.

Thank you.
Comment 9 Paolo Borelli 2013-03-11 20:41:03 UTC
Pushed to master and gnome-3-8 after the minor changes (spaces, split a new-location-dialog.ui and marked header buttons as can-focus).


If you want me to rebase the gjs experiments branch just let me know.