Python-EFL application template

Could you add that to Bullseye too?

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. :applause:

https://docs.enlightenment.org/python-efl/current/index.html

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. :thinking:

Here's a screenshot of 'mu-editor' running the sample from:
https://docs.enlightenment.org/python-efl/current/elementary/elementary.html#a-sample-python-elementary-program

Started a quicky using 'python-efl' and came up with this:

Where I left out the "lock" button as it also comes up in the 'log out' option.

Haven't finished it yet but I'll open it up on 'gitlab' once it's done. :work:

DONE:

It's on gitlab now:

Ah, I should've mentioned that. :face_with_head_bandage:
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. :thinking: )
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 :smiley: 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: :w00t:
    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. :smiley:

I think this format can be fairly useful for all the elive-tools. :thinking:
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. :applause:

Note(or tip):
'mu-editor' is a very nice way to run and test python apps .... it's in the repos. :slight_smile:

yes, is a pretty simple app :slight_smile: 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 :slight_smile: 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 :slight_smile: (elpanel was pretty much that)

Yes, efl is pretty easy and powerful at the same time :slight_smile:

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)

1 Like

Very nice.
Not all examples work. Like the one calling a systray, is a glaring example of that. :smiley:

Note:
'scite' does not compile python.

seems like there's multiple ways to run a source code :thinking: try Tools -> Go

Amazing! That works. :happy_dance:
'scite' is really far superior to 'mu-editor'.

I am going totally bonkers ....trying to add an icon to the button.

My code should do it but I get this:


Which isn't what I want but ..... if I click, I get this:


And it stays that way while it's running. :crazy_face:

and included by default :slight_smile:
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 :thinking: ), 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:

Remember: report bugs to PHAB about EDI

doesn't sounds it more like a bug? :thinking: that's why i prefer C... directly on the meant to be API lol

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. :clown_face:

  • Found it !

image

now to get some more whitespace around the icons

Umm, Bullseye too? :innocent:

I installed from the Buster repos without a problem for now.

  • I do find 'edi' extremely rudimentary in what it offers, not a finished by a long shot.

On a side note:

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. :innocent:

image

for me vim is more than enough for anything :slight_smile: 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 :slight_smile:

ah! starts to look better now :slight_smile:

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 :thinking: 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" :slight_smile:

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 :thinking:

mmh, not very convinced on the need for the resize-screen :thinking: (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:
    • things will look uglier
    • wasted pixels / inefficient shaping / wrong resolution
    • 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

2 posts were split to a new topic: python-EFL version of 'ctrl-alt-del' app