On a sidenote:
I've had a look at using python (3 on Bullseye) and after installing 'python-elf' using the elementary windows offer quite a bit of the desired output. On top it's independent of E16 or E25+ so it'll work on all
desktops.
So i'd say include 'python-efl' by default on future Elives so that Pythonistas can make use of it by simply calling the modules like: 'from efl import elementary' and knowing that the windows will work on all Elive machines.
Together with 'import os' to do system calls. with 'bash' or 'zsh' it shouldn't be too hard.
Thus using less GTK for everything that's Elive specific, this way.
Ah, I should've mentioned that.
My Bullseye uses python3 by default whereas Buster still has python2 in use.
So run it with python3 on buster (or maybe change the first line to python3 env. )
and keep an eye open if the module is installed to the right python version.
That's something we direly need to do too: Change over to python3, also on the current Buster based Elive version.
Can be done fairly easitly (I think) .... Like I said it was a quicky but by the look of things it's fairly do-able to copy your script one-on-one and only use the python-efl bindings for the GUI.
It can serve as a template for future GUI pop-ups and widgets. EFL can do a lot more than zenity has available.
Let's get messy:
All in all we can have it running from a shell script, setting all the variables already defined for zenity scripts... and then call 'python-efl' from that script and use the shell again from inside there.
In a python script we can ultimately define anything we want.
I think this format can be fairly useful for all the elive-tools.
It's as simple as creating a shell script and calling it from the python-efl GUI once a button is clicked.
Frankly I've only discovered this (python) GUI option as of today and I'm surprised how easy it is to apply.
Note(or tip):
'mu-editor' is a very nice way to run and test python apps .... it's in the repos.
yes, is a pretty simple app probably one of the simplest ones (especially to port it to other things like python / efl)
I'm not a python user, I would maybe do it directly on C lol, but yeah python offers many possibilities as a language and especially in combination of EFL which is so powerful and so many things can be done with that
yes of course it just faster for me to develop features / tools / things on zenity, and time is one of the critical factors on the elive development
there's a few problems with that:
if the GUI is a simple one, it doesn't matter much if is GTK or EFL, each one has good and bad things; gtk is more stable since efl has much more active and changing development, efl offers more possibilities but for a simple GUI it doesn't matter much
if the tool is moved to python i cannot maintain it anymore nor feature it nor update it with needed changes, I don't know python and the fluidity that i have using bash is thousands times faster than sending myself to the adventure to try to use a new language
Note: in the past there was a project called "enity" which meant to be as an EFL replacement of zenity, the idea was good and it worked with a few gui's, but it required some improvements and finally it was not used because of some extra things needed to be fully compatible (and i think because it used originally the ETK lib which is actually dead, i don't remember)
On the other hand, using EFL offer creating much better interfaces than just using elementary; aka elicit, elpanel, entrance (old version from elive-2.0 for example, etc)
Yes, a python-efl GUI interface calling a script is a good option too (elpanel was pretty much that)
Yes, efl is pretty easy and powerful at the same time
BTW I think not much people knows that, but scite is configured to be able to directly run C+EFL interfaces from it, the demo-files in the Live mode shows that (just open the .c file from scite, click run, and the compiled interface appears, quite funny to see). @triantares maybe it can be configured too for do the same with python+efl codes (if doesn't works directly by default)
Installing python-efl-doc it is worth to play with the example files on /usr/share/doc/python-efl/examples/ to see some of its possibilities (the documentation pointed by @triantares also shows may possibilities)
But also the ones in /usr/share/doc/libefl-dev/examples/ from the libefl-doc package, this one shows as much as EFL possibilities by its different libs (copy them to your home and open them with Scite, then click to Compile to run them)
and included by default
the conf files are not very intuitive, see also the file in /etc about scite
now i wonder how to make scite being able to "run python-efl codes" directly from it (in an easy/intuitive way ), i mean, like the compile/build buttons for the .c demo files... I wonder if there's a setting for that or there's a special conf for the .py format files to tell "how to compile"
talking about editors... I just added "edi" to the repos, the EFL IDE:
Well, I find hitting F5 very comfortable.
I edit, save and hit F5 to see what've done, or not.
Python doesn't need compilation, it's one of the reasons it exists.
What I do miss on 'scite' compared to 'mu-editor' is code completion.
Oh, it definitely is a bug in my code.
I'm sure it's got to do with the way I set up all the 'defs' and 'instances' separately, each on a line by themselves.
I want to keep it that way so as to make future editing (as a template) easier to navigate.
I don't think 'audio congiguration' should need to be in this menu .... considering the 3 fingered salute usually has to do with X crashing or freezing.
I would advise replacing it with 'scale desktop' or 'reconfigure screen-size' for those who are stuck with too small screens to even see or find menu- or window-buttons ---- Some might be quite relieved to have that option.
for me vim is more than enough for anything the one shipped with elive has many features (see .vimrc to know them, i need to write an article about that in the future, to show the good things included on elive)
but of course there's good ide's, and that's also a user preference
ah! starts to look better now
since ctrl-alt-del on windows is a fullscreen app, I would suggest to include an --argument to the tool that runs it in fullscreen mode (that is, a full-sized window, on top stacking, with a black background at 90% transparency if composite, and the buttons in the middle, + a cancel button in the bottom)
Yes! Im doing a lot of updates on bullseye recently (you may have noticed it), I'm even making the overall system for build isos, lot of work has been done on that in the last days
yeah maybe not so ready for the end use I assume it is meant to be the "E ide" but of course not much people uses it, it will need more work I assume... in any case you are welcome to report bugs or request changes on their phab so we can have a better "edi"
in fact it makes some sense, my coliving friend had a problem with his audio unable to speak on zoom, he didn't know how to solve that (on the mixer) and there's of course not a reset-audio option anywhere, while the ctrl-alt-end combo is something more like "I need to do something but I don't know how" lol, sounds good as an option to fix small things
by other side, maybe we will need in the future an own application for "reparations" (elive-nurse in the old versions of elive was that), but I don't think we need many things to repair in elive in fact
mmh, not very convinced on the need for the resize-screen (but still can be an option) because:
reconfigure screen sizes can be made from the preferences, unless as you said the user simply can't see, but:
the new beta versions automatically scales when the screen has smaller dpi's, so they are meant to always scale to correct sizes (but not buttons, that's a limitation of e16)
laptops should always use the highest resolution possible (their native one), otherwise:
there's no reason to change the resolution in a laptop screen (only in external displays)
while external displays or tower-computers:
still no reason to change the native resolution on TFT's/LCD's (unless wrongly detected, which can happen sometimes, or because e16 has a more limited xinerama system)
CRT's is another science, there's no optimal resolution (sometimes high resolution looks wrong), but in any of the cases they are not common to be more than 1024x768, so things on these screens will never look "too small" lol
but by the look of things it's fairly do-able to copy your script one-on-one and only use the python-efl bindings for the GUI.
