SARG wrote:@TFJ Come back to the good side of the Force ;-)
Who's TFJ ?-)
I am still at the good side of the Force. There're a lot of miss-understandings here, ATM.
AGS wrote:Glade and in particular a version of glade that supports gtk 3.x is unavailable on the windows platform.
I don't know where you get that information from, but it's simply wrong. Glade3 executables are available from
here: Glade-3.14.2.
Both of you can have full access to all source code files also on non-LINUX systems. (Somebody has to do the testing on that OSs, and I'm really happy that it's not me.)
AGS wrote:fbdbg.ui was nowhere to be found (it could be there and I simply overlooked it) but I am assuming it contains XML as produced by glade.
Yes, it contains XML. And the file isn't implemented in this documentation, because Doxygen isn't designed to parse XML source. (I don't know what happens when I include it. It's worth a try.)
AGS wrote:Meaning that SARG cannot maintain the gui himself. Unless, of course, he is willing to make a move to Linux as his main development platform and I don't think he is willing to do so.
First, switching to LINUX isn't the worst option.
Glade3 generates XML output. That is a human readable text file. You don't need Glade3 to manipulate that file (and therefor the GUI). I often use Geany to optimize (or correct) the Glade3 code, or to operate on a bunch of widgets at a time, ie. to replace some texts using regex.
It's easy to adapt texts in labels or tooltips that way, or to implement a further widget by duplicating an existend.
AGS wrote:We discussed using glade or some other tool in the fbdebugger thread. 'Low level GTK' was what was asked for. And right away you suggested using GtkAction (which is not low level gtk). After reading up on using GtkAction and related Gtk classes the choice for GtkAction made sense to me.
So what I was expecting to see was code not unlike what I found in example code on how to use the GtkUIManager. Lots of callback - code, some code to create the gui and of course a main program that glues it all together. But what I am finding here is a gui created using a combination of glade and gtkbuilder.
I am getting a bit confused here.
Yes, this is a confusing part of GTK+. And in addition, I do not really understand what you mean by 'Low level GTK' here.
There are three ways to create a GtkWidget:
- Classic coding line by line (Is this what you mean by low-level?)
- Parsing a STRING by a GtkUIManager (variables only)
- Parsing a STRING by a GtkBuilder (variables or file)
Each GUI toolkit supports classic coding. In contrast GTK+ offers two more possibilities to generate GUI elements from XML code. The code gets parsed at run-time, so the XML code is like a source code for a JIT compiler.
The first XML parser is the GtkUIManager. It is designed to generate menus and toolbars on the fly in the source code. It describes the widgets in a simple way. The syntax is easy to read and to edit, but not very powerful.
In contrast the GtkBuilder syntax is more complex, but also more powerful. While GtkUIManager can create toolbar and menu widgets only, GtkBuilder can generate any class that implements the GtkBuildable interface. Ie. it can also generate a GtkLabel, or a GtkFrame, or a GtkListStore, which isn't a complex GtkWidget but a simple GObject.
So GtkUIManager implements a subset of the GtkBuilder features in a less complex syntax. You can embed a GtkUIManager in a GtkBuilder object, but not the oposite.
All GtkBuilder features are also available as function calls (classic coding), but not the oposite. GtkBuilder is made for initially creating the widgets, but not to handle user actions.
BTW: The classic code is related to a certain programming language. In contrast, the XML file can be used by any code, writen in FB, C, Vala, JavaScript, ... It's not only cross-platform, it also allows polyglot coding. That's not an important feature here but a nice-to-have, anyway.
I can neither see a good, nor any reason to fallback to the GUI stone-age, to classic coding. But feel free to do the job of GtkBuilder and translate the Glade XML code to function calls, if you like. (The current file has about 4000 LOC, so you can be done in a week, or two.)
AGS wrote:Is SARG no longer interested in being able to maintain the gui himself?
I'm very interested in getting you and SARG being able to maintain the GUI without my help. I'm planing to switch from my productive role to a more consultant role soon, after getting the basics done.
AGS wrote:Is the gui you are presenting here just a mock - up and is the final code not going to be glade based but gtkuimanager based (='semi - low - level' gtk).
See above. GtkUIManager is designed to create toolbars and menus, but not to create a complex GUI.
The code isn't a simple mock-up anymore. I started coding for widgets data handling.
AGS wrote:Or are you planning to stick with the combination of glade and gtkbuilder? (in which case you'd have to persuade SARG to make a switch to Linux as his main development platform?).
IMHO this could be the final version (before doing text fixes and the packaging).
Regarding development platform: there's an other tool that wasn't discussed here, yet. The most time I spend on using Geany IDE. The second most time I use DevHelp, which is a simple HTML browser. It reads tag files from a bunch of directories (local on my HD) containing HTML trees (called books), and is able to jump on a certain documentation position (book->page->line) regarding the passed keyword.
Regardless if I work in Glade3 or Geany, when I press a key or the help button, DevHelp shows the related documentation (or a list of matches when the keyword is ambiguous). This works for any keyword, ie. in installed libraries like GTK, GDK, GIO, GLib, ..., or for the keywords in FB. All this books are linked to each other. This saves time, a lot of time.
I couldn't find a similar tool for non-LINUX systems yet. IHMO this DevHelp tool is the most important reason why you should consider to switch to LINUX. (But, please, only for development and NOT for testing.)
SARG wrote:About the log
The log is used to display/keep either data automatically written by the debugger or selected by the user.
---> screen , a gtk window (instead of the console window) with 2 buttons to clear / hide.
+ an entry in tools menu to show the window. If hidden, the window appears soon there is information to display.
---> file, a gtk window to display the current FIXED file with 2 buttons to delete the file / hide the window.
+ an entry in tools menu to show the window if hidden.
I guess 'FIXED file' = fixed file name.
OK, I can replace the entry by a simple checkbox. Or I copy your initial design (four radio buttons).
Anyway, I'd like to understand why you want to restrict the users freedom to choose a custom file name and why you want to show two windows with the same context -- screen and file. Isn't this confusing? And a waste of memory? I'd prefer a clearer concept: use an editor to watch the (any) file; the debugger offers an additional screen log window.
AGS wrote:And I simply have to write something about the doxygen generated documentation at ...
It looks great.
Thank you!
The credits don't belong to me. I just used the standard layout from Doxygen tool, which is responsible for that design (which can get customized as well).
SARG wrote:The documentation is very impressive, this will take me a bit of time to understand how information is organized
I'd like to think that both of you are willing to give Doxygen a try.
It should be easy to transform the current documentation pages to markup language, in order to fully integrate them in to the html tree.
SARG wrote:Reading the doc I found a shift in the variables of fbdbg.bas :
This was a test to find out if you check all pages. You stand the proof ;-)
So first Doxygen lessons here:
Documentational comments for Doxygen start with the magic character "*" right after the single quote (for both, single or multi line comments). By default they belong to the following source code construct. The magic character "<" makes them belong to the previous.
Here's the corrected snippet for
src/fbdbg.bas
Code: Select all
CONST PROJ_NAME = "fbdbg" '*< The project name
CONST PROJ_DESC = "FreeBASIC Debugger" '*< The project description
CONST PROJ_VERS = "3.0" '*< The version number
CONST PROJ_YEAR = "2015" '*< The year of the release
CONST PROJ_AUTH = "SARG, AGS, TJF" '*< The authors
CONST PROJ_MAIL = "Th0ma5.Fr3ih3rr@gmx.net" '*< An email address to get in contact
CONST PROJ_WEBS = "github.com/fbdbg" '*< The website where to find further informations
CONST PROJ_LICE = "GPLv3" '*< The licence of the project
As you can see, the resulting documentation gets generated from documentational comments, as well as from FB source. When you change a variable name, the documentation gets auto up-dated in the next Doxygen run (single source, saves a lot of work - only names in parameter lists have to get copied).
SARG wrote:My modest contribution of the day : a new icon sized 32 x 32 :
Thanks, implemented! I made the edge area transparent. (Later, you can replace my file if you don't like it.)
Any news regarding the GIT repo?