Migrate to gitlab

[mrmcq2u]

Might find it easier to find contributors if you migrate to gitlab.gnome.org

[mrmcq2u]

This would be a good step towards increasing visibility to translators

[gcad3d]

Is there a way to find cad/cam-oriented software on gitlab.gnome.org ?

[mrmcq2u]

The translation team has migrated over to gitlab - https://gitlab.gnome.org/Teams/Translation , I'm unsure as to what you are asking. There will be possibility of using gitlab pages in near future. Gcad3d is a great project, thank you for working on it. The purpose of the bug report was to see if your interested interested in having GNOME help in any way, e.g translations, design, infrastructure, packaging etc Thank you again.

[gcad3d]

CAD software companies have several 1000 developers, so of course we would need help. One big problem is the GUI. Gtk is good and an active community, but for technical applications too complex. We built a simple interface on top, which could be maintained easier when gtk changes. Maybe offtopic, but are there recommendations, help ?

[mrmcq2u]

There is work being done to try and simplify things for application developers with GTK4. There is a migration guide available already to help downstream devs understand what they need to get their codebase ready for the switch.

There is also the GTK development blog which is a good source of up to date information on what's happening with the next release and the reasoning behind why stuff is changing.
The report from the last hackfest was a particularly insightful read.
Looking forward to that layout branch landing soon myself 😃

For a more detailed idea of what is left upstream before 4.0 is released, you can look at the milestone on gitlab.

And if you have any questions or are having any difficulties then your more than welcome to provide feedback on discourse which is replacing the old mailing lists or you can have a chat on #GTK over at gimpnet.

Upstream GTK developers would be more than happy to have downstream users of the API give feedback on what difficulties they have had and whether the refactoring is a step in the right direction.

Honestly, I think GTK4 will reduce complexity for application developers but one way to make sure of that is to hear from developers like you.

Regardless of whether you would like to move over to Gitlab or not, I would just like to say thank you for writing this software and releasing it to the world. 🍻

[mrmcq2u]

You might also be interested in @chergert 's work on Designing for sandboxes, along with improving the overall security of your application his approach towards using GSubprocess also helps to isolate any misbehaving plugins.

The GDbus RPC might also be an interesting area to explore for you, @alexlarsson toyed with the idea back in 2012, the concept seems like it could be incredibly useful and it could be a good candidate for defining your core API separately from your GUI.

[gcad3d]

concerning "Designing for sandboxes" and GSubprocess and GDbus .. - what engineers dream of is something like tcl/tk - embedded into C. (tcl tk - since 1988, 50 millions google-hits, minimal changes of interfaces). For the next 10 days we will upload a new gcad version, then i will try to explain our (very buggy) approach (a gui-kit 'quick and dirty'  including the OpenGL-binding) Thanks for your effort and patience.

[mrmcq2u]

Yeah, I understand that it can be expensive to port the GUI to a target that has changed dramatically between major releases. The GTK developers are conscious of that as well which is in part why they have been pushing technologies like Flatpak forward so that for example downstream developers can continue using GTK3 with minimal pressure from distributors to transition their codebase.

It has been a difficult balancing act trying to simplify and improve the GUI stack while not making breaking changes but with GTK4 and the new release model, they have the freedom to look at things holistically and finally fix things once and for all so I think there will be less breakage going forward(GTK5 etc).

With regards to GSubprocess and GDus, well those are both parts of Glib and not GTK and Glib has been a lot more stable with regards to changes than GTK so you wouldn't need to worry much there.
Sandboxing might be interesting from a CAD/CAM perspective if you want to provide direct numerical control functionality e.g sandbox the loaders so that they don't have access to the network.

Anyway I look forward to hearing about your approach and hope to be able to help in some way.

[gcad3d]

Hallo, have now made a first summary of our GUI-problems / solutions (see below). Can you help to place this in the right place for the right people - eg Gtk- Discourse ? Greetings from vienna Franz ................................................................. A GUI-toolkit-C for technical applications Engineers need many, but very simple dialogs and menus;  something like tcl/tk - embedded into C  (tcl tk - since 1988, 50 millions google-hits, minimal changes of interfaces). Gtk ist for technical software developers very complex.  we develop technical software (see eg github.com/gcad3d, gcad3d.org);  at the moment gcad3d has 6427 GUI_- calls. When porting from gtk2 to gtk3  we made an interface between gtk and the application;  it makes the application independent from the gui-system  if the underlying gui-software changes only the interface must be adapted  it is a graphical user interface toolkit simplifying the design of GUI's   (a C - library with sampleprograms)   provides full OpenGL-integration (see example below)   Linux interfaces to Gtk2 or Gtk3, 32-bit or 64-bit.   MS-Windows (XP, Win7, Win8) interfaces to Gtk2   Functions use standard datatypes   have a unified callback-interface At startup: check if gtk3 or gtk2 is present, link to the appropriate libs   test if gtk (and OpenGL) is up; if not display errorMessage (with zenity) - file-read-write functions have support for directory-links   directory-links are supplied in a file with key-value-pairs:     eg "User1 /mnt/serv1/cadfiles";     filename "User1/xyz.jpg" gives "/mnt/serv1/cadfiles/xyz.jpg" - description interface-parameter opts (eg 3. parameter of GUI_gl__() in example)   set size horizontal, vertical, in pixels or charSize, expandable or not   character-string; separated by ','.     Eg "10e,e" = horiz.size 10 chars, hor. and vert. expandable.     Negative values = size in pixels; positive values = size ich characters. - unified callback-interface:   - first parameter (GuiObj *mo) is the caller;   - second parameter (void **data) provides all parameters;     the first parameter always is (int) eventID; eg TYP_EventMove     the following parameters are different;       GUI_gl_ev_move eg provieds two ints (the new mouseposition)   functions for getting the callback-parameters:     int GUI_DATA_EVENT returns the eventID;     int GUI_DATA_I1    returns the int following the eventID;     char* GUI_DATA_S1  returns a textstring following the eventID;     int GUI_DATA_I2    returns the int following GUI_DATA_I1 - example: main () {   GuiObj win1, box1 winGl;   // init   GUI_Init__ ("");   // Create Mainwindow   win1 = GUI_Win__ ("Gtk-Toolbox test", GUI_main_quit, "");   // get a vertical box in window   box1 = GUI_box_v (&win1, "");   // button in box   GUI_button__ (&box1, "press me", cb_button1, NULL, "");   // setUp OpenGL-window with size 200x200 pixels - expandable   winGl = GUI_gl__ (&box1, cb_gl_draw, "-200e,-200e");   // connect the mouse-move events   GUI_gl_ev_move (&winGl, cb_gl_move);   // connect the mouse-button events   GUI_gl_ev_button (&winGl, cb_gl_button);   // connect the keyboard-events   GUI_gl_ev_key (&winGl, cb_gl_key);   // windowSetup finished; display it ..   GUI_Win_go (&win1); } // callback of a GUI_button int cb_button1 (GuiObj *mo, void **data) {   GUI_MsgBox ("callback_button1"); } // callback of mousemove in OpenGL-window int cb_gl_move (GuiObj *mo, void **data) {   printf("cb_gl_move event=%d %d %d\n",          GUI_DATA_EVENT, GUI_DATA_I1, GUI_DATA_I2); } // callback of keyPress/release in OpenGL-window int cb_gl_key (GuiObj *mo, void **data) {   printf("cb_gl_key event=%d %d\n",          GUI_DATA_EVENT, GUI_DATA_I1);   // if(GUI_DATA_EVENT == TYP_EventPress) .. } // callback of OpenGL-window-events int cb_gl_draw (GuiObj *mo, void **data) {   printf("cb_gl_draw event=%d %d %d\n",          GUI_DATA_EVENT, GUI_DATA_I1, GUI_DATA_I2);   GUI_gl_set_active (1, mo);  // disactivate output to gl-window   // if(GUI_DATA_EVENT == TYP_EventConfig) { ..     // glViewport (0, 0, GUI_DATA_I1, GUI_DATA_I2); ..   GUI_gl_set_active (0, mo);  // reactivate output to gl-window } The toolkit has some bugs and the parameter-definitions should be improved. The OpenGL interface does not work for some Nvidia-cards with the Nvidia-binary- driver. At the moment the definition and implementation are quick and dirty; but maybe someone could help with improvements and/or upgrade to gtk4 .. // EOF