Page 3 of 3

Re: Help? GTK events do/dont's for dummies (nothing works)

Posted: Mon Jun 17, 2019 4:50 pm
by Mick P.
FWIW the paid (non-opensource) version of Xming is able to run the cube demo without the surface corruption issue exhibited by the Cygwin X server.

It can also run my software, mostly... it still occasionally goes into non-communicative mode. I'm trying to find superior ways to debug these things, but I'm pretty new to the scene. The generally recommended technique of using "--sync" is getting me nowhere. GTK refuses to consume it, and I cannot see a difference, on both Ubuntu and Cygwin. Though oddly Cygwin aborts on "sync" as unrecognized (command-line parsing system I've not yet dug into) but Ubuntu strangely does not. But it doesn't strip it from the arguments either. So I assume it's doing nothing.

If I had to bet, I'm thinking the corruption problem is the GTK2 path again. Xming is not a better server than Cygwin's I'd say overall in terms of visual compatibility. The Cygwin server has some true annoyances, like it cannot hide windows without destroying them. I tried to get them to fix this so glutHideWindow would work, but they still haven't. Since I'm writing my own GLUT layer I can now pseudo-hide the windows in various ways. Xming can't raise/lower windows or change their order. Generally these limitations probably only apply to "subwindows".

wxGLCanvas has an x11Direct member that appears to not be used:

https://github.com/wxWidgets/wxWidgets/ ... =x11Direct

It's a problem that it assumes direct connections. One X server I have (X410) flat refuses direct (DRI) connections. Part of the problem is lack of solid server options on Windows. I've written some user-agent code for them, but I have a filling there may be many more server options in the world outside Windows by comparison. It's a little unsettling to have to write code against unreliable agents, but it's not so different from web design.

Re: Help? GTK events do/dont's for dummies (nothing works)

Posted: Mon Jun 17, 2019 6:23 pm
by doublemax
Do you know if wxGLCanvas is a critical part of any major software with a large user base?
I don't know. There are a few applications listed at http://www.wxwidgets.org/about/screenshots/ that look like they would use wxGLCanvas. But they probably won't have "large" user bases.
The opengl examples (wx3.0-examples) should be adequate for that?
So you're saying the same issues are visible in the unmodified samples? In that case that would be a case for a bug report at http://trac.wxwidgets.org

Re: Help? GTK events do/dont's for dummies (nothing works)

Posted: Tue Jun 18, 2019 12:33 am
by Manolo
MickP, I see a lot of complains from you, never with enough code (or even worst: no code at all) that justifies your issues. That's not good if you want to get help. People may try to guess, or may try to correct some wrong comments. but that's all. Most of people will skip to other questions where they can be more helpful.

I taken a look at the code you posted on Thursday 13. It's difficult to follow. Too C-ish; and no "autoselfexplanatory" names. Can you write more pure C++? Can you avoid those nasty castings, specially (void*)?

What I would do in your case:
+ Put code for wxWidgets and glut in different files; and don't mix them, that's a can of worms.
+ Don't abuse "#define". Don't #define some already defined, like _() (which in wx is used for translations). Why do you create an operator named wxSize()? wxWidgets already have that name as a class.
+ Prefer names distinct not only in the uppercase.
And on top of that:
+ Start with a simple wxFrame. Put a wxGLCanvas inside it. Create a wxGLContext.
+ Add events handlers and draw something easy, just to check OpenGL and your handles work.
+ Study docs and samples for every feature you need.
Then, add progressively the complexity you wish.

If you do so, it's easy to narrow an issue, and it's also easier for people to help you, if you post the relevant code an the errors you get.

Re: Help? GTK events do/dont's for dummies (nothing works)

Posted: Tue Jun 18, 2019 12:11 pm
by Mick P.
Manolo, https://github.com/isocpp/CppCoreGuidelines is a good source for where current thinking is on best practices. Programmers have a lot of bad instincts. but the consensus is slowly getting better. Orthodoxies change. These are diametrically opposite of the prevailing wisdom of a decade ago, which still lingers.
Manolo wrote: Tue Jun 18, 2019 12:33 am MickP, I see a lot of complains from you, never with enough code (or even worst: no code at all) that justifies your issues. That's not good if you want to get help. People may try to guess, or may try to correct some wrong comments. but that's all. Most of people will skip to other questions where they can be more helpful.
You won't glean much from studying other peoples code. I don't recommend it. English is better! Though If you look closely at the code you'll see it is implementing virtually the entire GLUT framework in terms of wxWidgets, which thanks to wxWidgets can be done in one brief definition file. That's amazing =D>

I didn't make this topic to get assistance. I made it because the GTK side doesn't work. So I was looking for some advice on what works. I've since had a lot of time to massage the GTK code (edited: I mean "pathways" dedicated to GTK/GLX; not literally modifying wxGTK) to make it more-or-less work. It's not because the code is wrong. The foundation is wrong. But the real world is messy, and so code can be messy too. If we are too caught up in the intricacies of code it's a little loony tunes, like taking a broom outside to sweep up dirt off the ground!

Like I said somewhere in here (I apologize for the chaos) it's really not wxWidget's job to make GTK work. So it's not a criticism of wxWidgets. At least not if it's doing the best it can do. Which I don't know if it is or is not. But don't take criticism personally. They don't have to be emotionally weighty things. They can just be matter of fact acknowledgement of reality too.


EDITED: To clarify, when I say GTK "doesn't work" I mean that it doesn't operate like software, or like a machine. It operates more like a human being. In other words, it's completely chaotic, unreliable, error prone; you must check its work, and follow-up if it doesn't produce the desired work, etc. Which I suppose is kind of what you'd expect given the fact the free-software world is basically a jungle, and the system it's built on is a communication protocol. It's more like UDP than TCP. I.e. unreliable. So the same wxWidgets code that works for Windows--or other systems maybe too--massively doesn't work for GTK. So it needs lots of trial-and-error conditions to help it have acceptable outcomes. That's when you're glad wxWidgets is giving you a lingua-franca to write code in, even if these systems you're talking to have completely different "personalities' so-to-speak.

Re: Help? GTK events do/dont's for dummies (nothing works)

Posted: Tue Jun 18, 2019 3:14 pm
by ONEEYEMAN
Hi,
First of all I can assure you that when you talking software plain English is the worst language you can talk.
Second, remember GTK+ is written in pure C. Which means that there is no "nice" stuff C++ can give you - especially not C++11. So you should do a lot of stuff manually.

Thank you.

Re: Help? GTK events do/dont's for dummies (nothing works)

Posted: Wed Jun 19, 2019 1:34 pm
by Mick P.
doublemax wrote: Mon Jun 17, 2019 6:23 pm I don't know. There are a few applications listed at http://www.wxwidgets.org/about/screenshots/ that look like they would use wxGLCanvas. But they probably won't have "large" user bases.
CopperCube (http://www.wxwidgets.org/about/screenshots/) looks interesting for something I'd never heard about. Thanks.

https://www.ambiera.com/coppercube/
ONEEYEMAN wrote: Tue Jun 18, 2019 3:14 pm Hi,
First of all I can assure you that when you talking software plain English is the worst language you can talk.
Second, remember GTK+ is written in pure C. Which means that there is no "nice" stuff C++ can give you - especially not C++11. So you should do a lot of stuff manually.

Thank you.
Uh, maybe when it comes to "comments" in code code speaks louder than English, but not when it comes to discussions between people. Copy/pasting code is one step up from bleep-blooping at each other. On point #2 what language code is written in doesn't matter. It just matters if the code is sound. But what matters most is maintenance and maintainability. Usually less code is easier to maintain. That's cardinal rule #1.

EDITED: For the record, if by name-checking GTK+ your impression is I'm suggesting working with GTK or glib that's not what I mean to suggest. At least to make wxGLCanvas based windows work, pretty much every event handler has to branch based on what is the underlying system, since they have to all be handled differently. In a perfect world there would be no branches. And that's what a high-level system should deliver. Since it's easier to maintain code that doesn't have mixed logic embedded in it. And a high-level system can be written once, reused by many. But wxWidgets isn't high-level. So it's outside of its problem domain.

Ironically the UI library I'm developing on top of wxWidgets is called Widgets 95, and I ended up using the nickname XCV for it, because that's 95 in Roman numerals. It also happens to be the Querty keyboard sequence for cut/copy/paste and easy to type, so I don't know, it's interesting. If you make it an acronym it is WX (Widgets XCV) Or XW (XCV Widgets) which happens to be the same digraph wxWidgets uses. I'm maintaining a simplified version based on GLUI that I called GLUI Library, which in acronym form is GL, which is also in line with the traditional libraries attached to OpenGL. But the original GLUI library is an absolute birds nest of a mess. So it's not really the caliber of other libraries, but it integrates with GLUT, but it probably never worked well. My rewritten version (https://github.com/mick-p1982/glui) works perfectly, but is more or a stepping stone. My instincts attracted me to it because it reminded me of Win32, which I've spent a lot of time with. I saw it as potentially a way to port some Win32 classic style apps to cross-platform later on. That's why the successor is called "Widgets 95" too, a la Windows 95: https://sourceforge.net/projects/widgets-95/

Re: Help? GTK events do/dont's for dummies (nothing works)

Posted: Sun Sep 01, 2019 3:15 pm
by Mick P.
For the record, I recently ran into a problem that made absolutely no sense. It led me to notice the SetSize method has an additional flags parameter that includes bits for forcing the event to be processed, and also forcing the size to be applied...

That sounds like something that should not be required, unless there are gremlins. However, in my case, I have a low-level methodical system, that depends on processing events, due to dependent logic, and also it expects the sizes of the system objects to reflect the specified sizes; in which case, I haven't tested it, but I suspect a lot of the trouble with GTK likely falls into this category of events not happening when they are supposed to, and sizes being incorrect, so I'm hoping that when I get around to it, I will be able to get GTK to work reliably by using these flags.

Re: Help? GTK events do/dont's for dummies (nothing works)

Posted: Sun Sep 01, 2019 3:49 pm
by ONEEYEMAN
Hi,
All you trouble with the sizes/positioning of controls should go away when you start using sizers and abandon the idea of absolute positioning for good.

Thank you.

Re: Help? GTK events do/dont's for dummies (nothing works)

Posted: Fri Nov 08, 2019 7:33 pm
by Mick P.
ONEEYEMAN wrote: Sun Sep 01, 2019 3:49 pm Hi,
All you trouble with the sizes/positioning of controls should go away when you start using sizers and abandon the idea of absolute positioning for good.

Thank you.
I think I missed this, but anyway, that's no excuse!

There's nothing to use a sizer with, anyway, other than a dummy. With a wxGLCanvas it's just a window.

What I've found after turning to try to make wxGTK work with a big application, which has been a tortuous process... is that its SetSize and SetPosition methods work maybe 10% of the time. It's very evident when resizing via the diagonal that they don't work at all, except under maybe special conditions?

The first step to doing serious work was to link GTK's API into the project, which took me a while because it wasn't obvious how to do it with CMake, I eventually just stumbled upon a random something or other.

Its DoSetSize/DoMoveWindow code eventually gets to this code I think:

Code: Select all

static void pizza_size_allocate(GtkWidget* widget, GtkAllocation* alloc)
{
    wxPizza* pizza = WX_PIZZA(widget);
    GtkBorder border;
    pizza->get_border(border);
    int w = alloc->width - border.left - border.right;
    if (w < 0) w = 0;

    if (gtk_widget_get_realized(widget))
    {
        int h = alloc->height - border.top - border.bottom;
        if (h < 0) h = 0;
        const int x = alloc->x + border.left;
        const int y = alloc->y + border.top;

        GdkWindow* window = gtk_widget_get_window(widget);
        int old_x, old_y;
        gdk_window_get_position(window, &old_x, &old_y);

        if (x != old_x || y != old_y ||
            w != gdk_window_get_width(window) || h != gdk_window_get_height(window))
        {
            gdk_window_move_resize(window, x, y, w, h);

            if (border.left + border.right + border.top + border.bottom)
            {
                // old and new border areas need to be invalidated,
                // otherwise they will not be erased/redrawn properly
                GtkAllocation old_alloc;
                gtk_widget_get_allocation(widget, &old_alloc);
                GdkWindow* parent = gtk_widget_get_parent_window(widget);
                gdk_window_invalidate_rect(parent, &old_alloc, false);
                gdk_window_invalidate_rect(parent, alloc, false);
            }
        }
    }

    gtk_widget_set_allocation(widget, alloc);

    // adjust child positions
    for (const GList* p = pizza->m_children; p; p = p->next)
    {
        const wxPizzaChild* child = static_cast<wxPizzaChild*>(p->data);
        if (gtk_widget_get_visible(child->widget))
        {
            pizza->size_allocate_child(
                child->widget, child->x, child->y, child->width, child->height, w);
        }
    }
}
It never honors wxSIZE_FORCE, but I think this code should work except that the gdk_window_get_position, etc. APIs must not reflect the real coordinates the way it thinks it does. At least not for real windows if so.

To be able to diagonally resize windows at all I had to figure this out:

Code: Select all

		void what_is_wrong_with_wxGTK()
		{
			//Something is fundamentally broken when resizing diagonally.
			//I think it's the root of many problems.
			#ifdef __WXGTK__

			//Sometimes this fails and outputs warnings???
			auto gdk = gtk_widget_get_window(GetHandle());
			if(!GDK_IS_WINDOW(gdk)) return;
			
			int xx,yy,ww,hh; 
			
		//...
			//Works but wxWidget's internal position must be patched too.
			//gdk_window_move_resize(gdk,xx,yy,ww,hh);	
			m_x = xx; m_y = yy;
			m_width = m_clientWidth = ww; 
			m_height = m_clientHeight = hh;
			gdk_window_move_resize(gdk,xx,yy,ww,hh);
		}
EDITED: This code is added to the regular wxMSW logic to bring GTK builds into line.

After that I was able to apply this to most all size/position logic in my wrapper layer. Because wxWidgets is not portable in any sense of the word a wrapper is completely necessary to sanitize it. I guess it's hard for the "ports" to coordinate with each other. But a layer to bring them in alignment is essential I think for any mature application using wxWidgets. wxGTK is especially bad. I think it's probably the weak link as opposed to GTK or X11 workflow.

I'm not sure how sizers can improve it other than implementing the same tortured logic internally, but diversity in applications helps to identify fundamental errors in libraries. Only doing things one way is a good way to let issues hide in waiting, and obviously is not good conduct for a field with few to no alternatives. Believe me, if I could use anything other than wxWidgets I wouldn't hesitate.

(Because wxWidgets is so crummy it would help many things if the "private" keyword were outlawed in its guidelines, and it should use `virtual` more generously to give developers a way out. I find it impossible to use wxWidgets without keeping the source code handy and applying spot fixes by way of consulting its code, and reproducing it. You hope such work doesn't break down the road, but you have no alternative.)

Re: Help? GTK events do/dont's for dummies (nothing works)

Posted: Fri Nov 08, 2019 9:12 pm
by ONEEYEMAN
Hi,
Well, I am almost guarantee that if you give me access to the design you are trying to achieve - I will make it work on all 3 major platforms with sizers and the main wxWidgets line (C++, no additional hacks) in 5 min.

Just because you refuse to use something properly (by properly I mean "like 99% of wxWidgets users) doesn't mean that the code is buggy.
Yes - the library has bugs (and a lot of them - just look at trac.wxwidgets.org), but not in the area where you are finding them and trying to work around the stuff that will probably nobody will ever care.

My guess is that you are coming from the MSVC world where you have a GUI designer based on the absolute positions and absolute size. I was in the same boat. I came to wxWidgets being completely Windows developer with MSVC.

But now I can't live without the sizers architecture. Learn it - it will save you time and money in the long run.

Thank you.

Re: Help? GTK events do/dont's for dummies (nothing works)

Posted: Sun Nov 10, 2019 5:50 am
by Mick P.
A sizer is for a layout, it doesn't help with absolute positioning. In any case I think it would surely work if wxGTK implemented the immediate pass-through option, but since it doesn't it gets the events out of order or something. I'm not sure why you are so confident. Basic positioning doesn't seem to work either. I think that these paths are just not considered because wxWidgets doesn't implement the full expressiveness of its API. And I've encountered multiple interfaces that simply don't work, or explode. Like wxMSW can't reparent a top-level window, meaning that no one's ever tried to, or users are used to working around wxWidgets with #ifdef code, that it actively encourages by refusing to provide a portable API. At least with a test application it should be possible to identify all of the deficiencies and demonstrate completeness.
My guess is that you are coming from the MSVC world where you have a GUI designer based on the absolute positions and absolute size. I was in the same boat. I came to wxWidgets being completely Windows developer with MSVC.
No, the top-level building blocks are GLUT/X style subwindows. There isn't a notion of tiling. Inside of them there is an OpenGL based layout engine that is very good. So, if I do get around to using native controls (as user preference) yes they will too be absolutely positioned. The layout engine is tied to a high-level C++ data-oriented framework far better than wxWidget's unworkable API, so it makes sense to not maintain separate pathways, and just reuse the layout engine. My interest in wxWidgets is system unification, reducing code and concepts. Not building within the confines of a one-size-fits-all application model.

Re: Help? GTK events do/dont's for dummies (nothing works)

Posted: Sun Nov 10, 2019 6:36 pm
by ONEEYEMAN
Hi,
Mick P. wrote: Sun Nov 10, 2019 5:50 am A sizer is for a layout, it doesn't help with absolute positioning.
This accusation is based on what?
Mick P. wrote: Sun Nov 10, 2019 5:50 am In any case I think it would surely work if wxGTK implemented the immediate pass-through option, but since it doesn't it gets the events out of order or something. I'm not sure why you are so confident. Basic positioning doesn't seem to work either. I think that these paths are just not considered because wxWidgets doesn't implement the full expressiveness of its API. And I've encountered multiple interfaces that simply don't work, or explode. Like wxMSW can't reparent a top-level window, meaning that no one's ever tried to, or users are used to working around wxWidgets with #ifdef code, that it actively encourages by refusing to provide a portable API. At least with a test application it should be possible to identify all of the deficiencies and demonstrate completeness.
Well, I didn't see you posting a singe line of code to prove the points you are making.
All you do is keep wining about how bad wxWidgets is.

So I encourage you to create couple of small applications which are self-contained, then create a patch against minima application and submit this as a bug to the trac,
However, I have a feeling you will not do that.
Mick P. wrote: Sun Nov 10, 2019 5:50 am
My guess is that you are coming from the MSVC world where you have a GUI designer based on the absolute positions and absolute size. I was in the same boat. I came to wxWidgets being completely Windows developer with MSVC.
No, the top-level building blocks are GLUT/X style subwindows. There isn't a notion of tiling. Inside of them there is an OpenGL based layout engine that is very good. So, if I do get around to using native controls (as user preference) yes they will too be absolutely positioned. The layout engine is tied to a high-level C++ data-oriented framework far better than wxWidget's unworkable API, so it makes sense to not maintain separate pathways, and just reuse the layout engine. My interest in wxWidgets is system unification, reducing code and concepts. Not building within the confines of a one-size-fits-all application model.
Did you even tried to learn and understand sizers? Did you try to create something based on different sizers? Did you build and run the layout sample?

Like I said you just coming here from MSVC world where everything is absolute.

As I said - give me you code and I will make it sizers-based where everything will just work.

Thank you.

Re: Help? GTK events do/dont's for dummies (nothing works)

Posted: Tue Nov 12, 2019 4:16 am
by Mick P.
ONEEYEMAN wrote: Sun Nov 10, 2019 6:36 pm This accusation is based on what?
Accusation?
Mick P. wrote: Sun Nov 10, 2019 5:50 am Did you even tried to learn and understand sizers? Did you try to create something based on different sizers? Did you build and run the layout sample?
No, I have work to do. Every UI framework has layout elements. But they position controls relative to other controls. Absolute-positioning is by definition not relative to anything. So, it's not applicable. Automatic layout is great. That's why my project uses it, via a different framework from wxWidget's. It even automatically manages titles, so it's further removed from something like Win32 common-controls practices than wxWidgets is.
As I said - give me you code and I will make it sizers-based where everything will just work.
Here (below) is some typical code for a wizard like dialog that uses tabs. It sets background images to assist with editing a 3d model. You can see 1) it doesn't use wxWidgets. 2) it has sizers, like the "row" element, and the "tab" element is a basic container that is like a vertical stack sizer (not the tabs themselves) that can have column elements placed to start a new stack at the top. The "row" is an inline element, as-if every element inside of it has a column between it and the next element. You can't use wxWidgets for this purpose because OpenGL renders the elements, but it could be made to use system controls, but all of that is behind the scenes. It doesn't expose wxWidgets, and why would it. Since you mention Win32 you can see that there is just one procedure that uses IDs, which tends to be cleaner design than using function pointers. With C++11 you can even initialize the members outside of the constructor, but I tend to think it's more readable to do in the constructor, even if it means writing them twice. You can see why this is better than using wxWidgets directly. It's ported from Qt code that accomplished the same thing with many more files, several callbacks, and seemingly needing every little thing spelled out for it, as is typical of system APIs.

This is single window dialog, so it doesn't even require positioning outside the frame itself. I came back here just to report it occurred to me that wxGTK might need the "Skip" practice in its MOVE/SIZE events. I thought it might be that simple... I'd probably tried that before... surely, but anyway, it didn't help either.

Code: Select all

struct BackgroundWin : Win
{
	void submit(int);

	BackgroundWin(Model *model)
		:
	Win("Select Background Image"),
	model(model),
	tab(main,id_item),
	scene(tab,id_scene),
	browse_nav(tab),
	source(browse_nav,"",id_source),
	browse(browse_nav,"...",id_browse),
	f1_ok_cancel(main),
	texture(scene,false)
	{
		tab.lock(false,320);

		tab.add_item("Front").add_item("Back");
		tab.add_item("Left").add_item("Right");
		tab.add_item("Top").add_item("Bottom");
		
		browse_nav.expand().space(0);
		source.expand(); 
		browse.ralign().span(0).drop(source.drop());

		active_callback = &BackgroundWin::submit;

		glutSetWindow(glut_window_id()); //texture
		submit(id_init);
	}

	Model *model;		

	ui::tab tab;
	canvas scene;
	row browse_nav; 
	textbox source;
	button browse;
	f1_ok_cancel_panel f1_ok_cancel;

	Widget texture;
};
void BackgroundWin::submit(int id)
{
	switch(id)
	{
	case id_init: 
	
		texture.setModel(model);
		//break;

	case id_item:

		source.text() = model->getBackgroundImage((int)tab);
		
		/*if(0) case id_delete:
		{
		source.text().clear();	
		}*/
		if(0) case id_browse:
		{
		std::string verb = "Open: ";
		//FIX ME 
		//"all model formats" doesn't include parentheses ???
		verb+=::tr("All Supported Formats (","all texture formats");
		verb+=TextureManager::getInstance()->getAllReadTypes();
		verb+=')';

		std::string file = config.get("ui_background_dir");
		if(file.empty()) file = ".";
		file = FileBox(file,verb,::tr("Open texture image"));
		if(file.empty()) 
		break;						
		source.text() = file;
		config.set("ui_background_dir",file,file.rfind('/'));		
		}
		//break;

	case id_source:
			
		model->setBackgroundImage((int)tab,source.c_str());
		
		if(source.text().empty())
		{
			texture.setTexture(-1,nullptr);
		}
		else if(Texture*t=TextureManager::getInstance()->getTexture(source))
		{	
			texture.setTexture(-1,t);
		}
		else
		{
			Texture::ErrorE e = TextureManager::getInstance()->getLastError();
			msg_error("%s\n%s",source.c_str(),
			e==Texture::ERROR_NONE?::tr("Could not open file"):textureErrStr(e));			
		}
		
		source.set_text(source); //Finally, set the text properly.

		break;

	case id_scene:

		texture.draw(scene.x(),scene.y(),scene.width(),scene.height());
		break;

	case id_ok:

		model->operationComplete(::tr("Background Image","operation complete"));
		break;

	case id_cancel:

		model->undoCurrent();
		break;
	}

	basic_submit(id);
}
extern void backgroundwin(Model *m){ BackgroundWin(m).return_on_close(); }
If you want my two cents, I don't understand why you're so adamant that wxWidgets should be used for every single thing instead of seeing it as an abstraction layer for system APIs. When you use the system API there is no call to use it for everything, and that's just what wxWidgets is. It doesn't have to be a cult. It can just be a high-level system API.

Re: Help? GTK events do/dont's for dummies (nothing works)

Posted: Tue Nov 12, 2019 4:52 am
by ONEEYEMAN
Hi,
Mick P. wrote: Tue Nov 12, 2019 4:16 am
ONEEYEMAN wrote: Sun Nov 10, 2019 6:36 pm This accusation is based on what?
Accusation?
Yes, accusation.
Mick P. wrote: Sun Nov 10, 2019 5:50 am
ONEEYEMAN wrote: Sun Nov 10, 2019 6:36 pm Did you even tried to learn and understand sizers? Did you try to create something based on different sizers? Did you build and run the layout sample?
No, I have work to do. Every UI framework has layout elements. But they position controls relative to other controls. Absolute-positioning is by definition not relative to anything. So, it's not applicable. Automatic layout is great. That's why my project uses it, via a different framework from wxWidget's. It even automatically manages titles, so it's further removed from something like Win32 common-controls practices than wxWidgets is.
They don't. Who tod you that?
You know an example of such framework?
I know in JAVA layout is done based on the NORTH, WEST, EAST, SOUTH and CENTER. I know GTK layout is very close to wxWidgets one.
So, I need proof, please.
Mick P. wrote: Sun Nov 10, 2019 5:50 am

Here (below) is some typical code for a wizard like dialog that uses tabs. It sets background images to assist with editing a 3d model. You can see 1) it doesn't use wxWidgets. 2) it has sizers, like the "row" element, and the "tab" element is a basic container that is like a vertical stack sizer (not the tabs themselves) that can have column elements placed to start a new stack at the top. The "row" is an inline element, as-if every element inside of it has a column between it and the next element. You can't use wxWidgets for this purpose because OpenGL renders the elements, but it could be made to use system controls, but all of that is behind the scenes. It doesn't expose wxWidgets, and why would it. Since you mention Win32 you can see that there is just one procedure that uses IDs, which tends to be cleaner design than using function pointers. With C++11 you can even initialize the members outside of the constructor, but I tend to think it's more readable to do in the constructor, even if it means writing them twice. You can see why this is better than using wxWidgets directly. It's ported from Qt code that accomplished the same thing with many more files, several callbacks, and seemingly needing every little thing spelled out for it, as is typical of system APIs.

This is single window dialog, so it doesn't even require positioning outside the frame itself. I came back here just to report it occurred to me that wxGTK might need the "Skip" practice in its MOVE/SIZE events. I thought it might be that simple... I'd probably tried that before... surely, but anyway, it didn't help either.
Are you porting something to wxWidgets?
Because if not - I need to understand what this diaog is about.
And why are you introducing OpenGL in the simple diaog?

My understanding of OpenGL is that it is a system for 3D rendering. And so this dialog IIUC, should just be a diaog to set up some drawing parameter.

BTW, OpenGL control can be put in the window and the window can be put in a sizer.
Mick P. wrote: Sun Nov 10, 2019 5:50 am

Code: Select all

struct BackgroundWin : Win
{
	void submit(int);

	BackgroundWin(Model *model)
		:
	Win("Select Background Image"),
	model(model),
	tab(main,id_item),
	scene(tab,id_scene),
	browse_nav(tab),
	source(browse_nav,"",id_source),
	browse(browse_nav,"...",id_browse),
	f1_ok_cancel(main),
	texture(scene,false)
	{
		tab.lock(false,320);

		tab.add_item("Front").add_item("Back");
		tab.add_item("Left").add_item("Right");
		tab.add_item("Top").add_item("Bottom");
		
		browse_nav.expand().space(0);
		source.expand(); 
		browse.ralign().span(0).drop(source.drop());

		active_callback = &BackgroundWin::submit;

		glutSetWindow(glut_window_id()); //texture
		submit(id_init);
	}

	Model *model;		

	ui::tab tab;
	canvas scene;
	row browse_nav; 
	textbox source;
	button browse;
	f1_ok_cancel_panel f1_ok_cancel;

	Widget texture;
};
void BackgroundWin::submit(int id)
{
	switch(id)
	{
	case id_init: 
	
		texture.setModel(model);
		//break;

	case id_item:

		source.text() = model->getBackgroundImage((int)tab);
		
		/*if(0) case id_delete:
		{
		source.text().clear();	
		}*/
		if(0) case id_browse:
		{
		std::string verb = "Open: ";
		//FIX ME 
		//"all model formats" doesn't include parentheses ???
		verb+=::tr("All Supported Formats (","all texture formats");
		verb+=TextureManager::getInstance()->getAllReadTypes();
		verb+=')';

		std::string file = config.get("ui_background_dir");
		if(file.empty()) file = ".";
		file = FileBox(file,verb,::tr("Open texture image"));
		if(file.empty()) 
		break;						
		source.text() = file;
		config.set("ui_background_dir",file,file.rfind('/'));		
		}
		//break;

	case id_source:
			
		model->setBackgroundImage((int)tab,source.c_str());
		
		if(source.text().empty())
		{
			texture.setTexture(-1,nullptr);
		}
		else if(Texture*t=TextureManager::getInstance()->getTexture(source))
		{	
			texture.setTexture(-1,t);
		}
		else
		{
			Texture::ErrorE e = TextureManager::getInstance()->getLastError();
			msg_error("%s\n%s",source.c_str(),
			e==Texture::ERROR_NONE?::tr("Could not open file"):textureErrStr(e));			
		}
		
		source.set_text(source); //Finally, set the text properly.

		break;

	case id_scene:

		texture.draw(scene.x(),scene.y(),scene.width(),scene.height());
		break;

	case id_ok:

		model->operationComplete(::tr("Background Image","operation complete"));
		break;

	case id_cancel:

		model->undoCurrent();
		break;
	}

	basic_submit(id);
}
extern void backgroundwin(Model *m){ BackgroundWin(m).return_on_close(); }
If you want my two cents, I don't understand why you're so adamant that wxWidgets should be used for every single thing instead of seeing it as an abstraction layer for system APIs. When you use the system API there is no call to use it for everything, and that's just what wxWidgets is. It doesn't have to be a cult. It can just be a high-level system API.
No, definitely not for everything.
But it seems that you come to wxWidgets world trying to use the library for something that it is not designed for.

wxWidgets uses native controls/widgets whenever possible.
You software needs to paint controls itself.

Thank you.

Re: Help? GTK events do/dont's for dummies (nothing works)

Posted: Wed Nov 13, 2019 7:13 am
by Mick P.
They don't. Who tod you that?
If not I would not call something a UI framework, since it's too low-level to do layout if it doesn't provide meaningful layout facilities.

I think you're playing cat and mouse with me. Yes the system uses wxWidgets to implement itself. In OpenGL mode it uses wxGLCanvas and can use menu and toolbar if displaying a window normally. After it's more mature I will see about using native controls as drop in replacements, as explained only one or two replies up.

What the code illustrates is that there isn't wxWidgets code per se, so it's not in a position to apply wxWidget's sizers to, and that it wouldn't make sense to anyway, but that wxWidgets can still abstract the native system controls, without sizers.