Drop-in Replaceable components

BlitzMax Forums/Brucey's Modules/Drop-in Replaceable components

Brucey(Posted 2014) [#1]
Much in the way you can add different types of image loader support to BlitzMax, and how the HTMLView modules work in GTKMaxGUI, I was thinking it may also be (kinda) cool to be able to do similar things with the likes of a TextArea gadget.

So, for example, you have the default TextArea, but if you provide a new type (say, a scintilla-based one), it would use that instead of the default, checking if there are any others available during initialisation.

This way you can pick and choose what you need for any given application - basic HTML support and a decent editor ; a good web viewer and the default editor; etc.

Choice is fun...


Derron(Posted 2014) [#2]
Would surely be a nice addition -- but just for some of us users.

Where do you see the exact advantage to just using the "extended" version right from start. The more easier "change" if somebody provides a better/more-detailed/less depending one ?


bye
Ron


Brucey(Posted 2014) [#3]
Dunno. Just seems like an interesting way of perhaps not including everything in one - and only choosing the bits you need.
Although most people seem to prefer not to use Framework and get everything for free anyway :-p


xlsior(Posted 2014) [#4]
By the way: Looks like some of your new tweaks don't compile under Windows at the moment:

Latest SVN sync:

bmk makemods -a bah.gtkwebkitgtk

Compiling:gtkwebkitgtk.bmx
Compile Error: Type 'TGTKWebDriver' not found
[c:/Code/Blitzmax/mod/bah.mod/gtkwebkitgtk.mod/gtkwebkitgtk.bmx;54;1]
Build Error: failed to compile c:/Code/Blitzmax/mod/bah.mod/gtkwebkitgtk.mod/gtkwebkitgtk.bmx



Brucey(Posted 2014) [#5]
Thanks. Fixed.


Brucey(Posted 2014) [#6]
This is how the drop-in TextArea replacement looks in action, in the IDE :


(Linux MaxIDE 1.43 GTK+ native with Scintilla TextArea and WebKit help)

Just by Importing the module, it is seamlessly used in preference to the default TextArea.


Derron(Posted 2014) [#7]
Just a short question:
Below the list of opened files... just below "[Help]" you might see that odd grayish area coming out of a sudden - covering that "sleak" bordered white background ... same on the right (just the connection of the upper-scrollbar-part and the background).

Same for the right-navigation bar.

So: is this a matter of your gtk-"implementation" or a theming-issue?


Comparison:



All in all: a nice and welcome improvement - as you know - I do not trust the MaxIDE-textarea as undo/redo was way too bugged some years ago ... I do not want to loose code I sweatened out of my hands :D


bye
Ron


Brucey(Posted 2014) [#8]
It's my implementation for MaxGUI.
The problem with MaxGUI, as has always been, is that you need to support the lowest common denominator, and presumably the Windows tab bar doesn't actually have a real concept of child widgets. Therefore MaxGUI doesn't really have a concept of "natural" child widgets, and it has been hacked around a bit to implement it.

Exciting, isn't it? :-)


degac(Posted 2014) [#9]
Interesting!
So are you working on a 'modular' version of MaxGUI (at least on Linux and for some gadgets)?

I understand the 'limit' to support the lowest common denominator, but MaxGUI was designed to be light & ready for 3 platforms with a unique source.
This means some platform specific charateristic (just thing to visual of gadget on iOS) are missing.
Or just think to label gadget: once created you cant' change the style of the gadget.

What is(are) your solution(s) for this?
Without polemic, just to know an alternative vision!
Maybe a complete rewrite of the 'machine under the curtain' will be a better solution: but it has a cost (and more: who want to do it without some returns?)


Derron(Posted 2014) [#10]
@without some returns
I think Brucey proofed already that he can do many things without return ... think the "price" we have to pay is: support him with testing things. The price he wants is: having fun when doing things in his sparetime ...

But maybe Brucey isn't the mother Teresa of BlitzMax and at the end he wants world supremacy :D


@lowest common denominator: Another reason not to use MaxGUI for real crossplatform tools. Like I mentioned in the thread of the RTS-Creator: things need a specific visual level to get accepted by normal users. If someting look odd they might loose trust in the program itself... nothing we want, do we?

I know that certain "widgets" are not available in a native version on all OS and of course it might be a problem of GTK (they had some problems in 2002 with the tab widget :D) but as other GTK-using-applications use it I think Brucey is right about "child widgets".

Wouldn't it be possible to add "padding" to all widgets? I am not really used to MaxGUI and its sources but in my inGame-GUI I have padding which gets used when calling GetContentScreenX(), GetContentScreenWidth() etc.
These are then the functions which get called as soon as a children calls its GetScreenX() (for display purposes) or GetX() for getting the distance to the "0,0" of a parent. If no parent was set ... local values are returned.

Next step then would be the retrieval of system"padding"-definitions.


Of course all the above things are more "offtopic" than needed and I hope it does not sound as disrespect to the "Drop-In replacements" Brucey is working on.


bye
Ron