Kivy is not for me

[Claudio]

I'm very impressed about what Python enthusiasts were able to build with
this Kivy framework! The amount of features is huge and I like very
much the possibility of splitting the functions and the layout description
into different files. So I really appreciate the huge work which has
been done over all the years.

But after three projects I can tell you the following: if you want to
waste very much time - use Kivy! It's the strangest framework I've ever
seen in my long experience of GUI programming! Qt for Android is
suprisingly stable but does not respect any Android style guides and also
seems like an alien app on your phone. So the next try will be something
more web-based like Flask or something similar.

So here is a list of things I learned - just to give you a view "from
outside" - I don't want to blame Kivy - maybe it challanges you to work
on some points?

1. Things are always the opposite way than you know it. For instance if
   you are used to implement on_press events, you should use on_release.
2. The Kv langauage is the strangest thing you can imagine. It does not
   remind anything you already know.
3. There is much magic around. It's by chance if you take the right way
   to address an ID or class: just try 'self' then 'root' then 'app' and
   at the end 'root.dispatch()'. There's no guide how you can get the
   right addressing except by googling hours.
4. Layouts do not work like you know for instance from Qt. If you add an
   image to a label, it paints anywhere on screen - no matter what layout
   you have chosen.
5. Once you think your GUI is pretty enough you can change anything in
   the Kv file and everything messes up. For instance if you have to
   many indentation and you try to extract it in a separate declaration
   you can start at zero with your GUI. It breaks your whole layout.
6. Changing size_hint/width/height/pos_hint/x/y does most of the time
   nothing but if it does it breaks the whole layout. So you can spend
   hours for just placing an image on the top of an other widget.
7. Image handling is very primitive - you will spend hours just to add
   an image to a button which also contains a text.
8. One of the worst thing you can use are the ActionBars. Completly
   unexpected behavior and most of the items are undocumented. Try to
   add so many items to a group that it needs a scroll bar - you will
   regret it, because you can't press the buttons any more.
9. Even worse is a simple multiline TextInput showing 25 kB of text: you
   can't even scroll the text.
10. But the worst thing which can happen are ListViews! They are simply
    so bad implemented that you can go and get a coffee if you want to scroll
    to the last of just 100 items. The replacement called RecycleView
    couldn't be called stranger - please think about the users who are new
    to Kivy.
11. Kivy is completly useless for Desktop applications. A self made file
    chooser like this is not an option. This is really the killer.
    On the other hand Qt for Android is useless too.

So what? I would propose fewer magic and clearer layout handling which will
bring more lines of code and therefore more implementation work, but at the
end, it will save much time you need for fixing broken layouts...

Thankg for you patience reading this and hopefully gives some ideas you
could work on...
Claudio

[Ray A]

Thats really unfortunate. Same experience here.

I have spent so much time to learn Kivy and built a simple app, built it by Buildozer successfully,  but it didn't work on Android.

Spent hours and hours googling, reading and trying to find out what the problem is.... no luck.

I was very exited at the beginning... but I feel that I have no choice but to leave it now.....

Sad...

[Gabriel Pettier]

Hello First, it seems there are quite fundamental things about kivy that you missed, which means either you didn't read the documentation, or we did a pretty bad job at explaining them, but i'm quite impressed that you could go through 3 projects without understanding them. That's a weird thing to start on, it's really a convention, we have two events here, it's up to you to decide on which to bind, and if you change your mind, pretty easy to change. Kv lang is inspired by yaml and by qml, sure, it's not exactly the same, but it's not completly out of nowhere. I'm pretty sure that's explained in the documenation, but i'll restate it here: app simplest of them all, always refer to your App instance. self always refer to the innermost widget you are into, look lines up until you find a widget class name, that's the widget you are talking about root always refer to the outermost widget you are into, look lines up until you find one that is not indented at all, that's the widget you are talking about Layouts manage the position of all their direct children, if you nest something in a widget, it's not affected anymore by the layout. Doing what you are asking for here can be easy: FloatLayout: Button: id: button size_hint: .5, .5 pos_hint: {'center': (.5, .5)} Image: source: 'images/image-loading.gif' size: button.size pos: button.pos # you can add another label at the top of it, if the image hides the button's text Label: text: button.text pos: button.pos size: button.size But you could also do your own ImageButton class, and use it as many time as you want <ImageButton@ButtonBehavior+Image>: # is an Image with a button behavior, has on_press/release, etc text: '' # add a label at the top to display text atop the image Label: text: root.text size: root.size pos: root.pos text_size: root.size I pretty often refactor a specific widget into a rule, it's not very different from taking out python code and make it into a function, cut, paste, unindent as much as needed, add a "header" (here new widget name), and the parameters, then use it at the previous place… Not sure if your editor is getting in the way somehow, or if you have a more specific issue you want to share. see #4 plus Layouts use size_hint and pos_hint to manage children's size/pos automatically, so pos/size won't have any effect in a layout's children unless size_hint/pos_hint allows them to. Other widgets don't use size_hint/pos_hint, so only pos/size will have an effect see the answer to #3, or give more details, in my experience Image is simple, but very flexible. Can't answer here, because i don't use that, but that looks like an issue with scrolling, which delay touches, that's an issue with kivy i'm willing to concede, our default values for scroll_timeout and scroll_distance are far from perfect, but you can tweak them, and improve things a lot. You might want to use a specific widget if you have large amount of text to display, although TextInput does allow scrolling, it does so differently from ScrollView, i would advice (if it's only for display), using a RecycleView. ListView is deprecated for a good reason, it's developpment didn't go the way we intended, it's API doesn't allow for good performances, as you noted, it's now replaced by RecycleView, we strongly advise everybody to switch. RecycleView itself works a bit differently, but you just need to pass a list of dicts containing your data, and the widget that will display them, to your layout. I know there is only one example in the documentation, but it's a good starting point, and some experimentation should clarify things. If not, questions are always welcome. Kivy focuses on its own set of widgets, but sometime you want a native look, not a common UI on all platform, and it's fine, for these things, plyer offer some answers, and one of them is a FileChooser that uses the native platform one. You might want to have a look. Criticism is always welcome, maybe our concepts are flawed or maybe we need to better explain them. But i personally build kivy apps at work at quite a decent speed, and i see others able to do the same, what takes is time is usually bugs that have to be fixed or worked around, not the general logic of the framework.

On Sat, Oct 07, 2017 at 01:43:27AM -0700, Claudio wrote:

I'm very impressed about what Python enthusiasts were able to build with this Kivy framework! The amount of features is huge and I like very much the possibility of splitting the functions and the layout description into different files. So I really appreciate the huge work which has been done over all the years. But after three projects I can tell you the following: if you want to waste very much time - use Kivy! It's the strangest framework I've ever seen in my long experience of GUI programming! Qt for Android is suprisingly stable but does not respect any Android style guides and also seems like an alien app on your phone. So the next try will be something more web-based like Flask or something similar. So here is a list of things I learned - just to give you a view "from outside" - I don't want to blame Kivy - maybe it challanges you to work on some points?

Things are always the opposite way than you know it. For instance if you are used to implement on_press events, you should use on_release.

The Kv langauage is the strangest thing you can imagine. It does not remind anything you already know.

There is much magic around. It's by chance if you take the right way to address an ID or class: just try 'self' then 'root' then 'app' and at the end 'root.dispatch()'. There's no guide how you can get the right addressing except by googling hours.

Layouts do not work like you know for instance from Qt. If you add an image to a label, it paints anywhere on screen - no matter what layout you have chosen.

Once you think your GUI is pretty enough you can change anything in the Kv file and everything messes up. For instance if you have to many indentation and you try to extract it in a separate declaration you can start at zero with your GUI. It breaks your whole layout.

Changing size_hint/width/height/pos_hint/x/y does most of the time nothing but if it does it breaks the whole layout. So you can spend hours for just placing an image on the top of an other widget.

Image handling is very primitive - you will spend hours just to add an image to a button which also contains a text.

One of the worst thing you can use are the ActionBars. Completly unexpected behavior and most of the items are undocumented. Try to add so many items to a group that it needs a scroll bar - you will regret it, because you can't press the buttons any more.

Even worse is a simple multiline TextInput showing 25 kB of text: you can't even scroll the text.

But the worst thing which can happen are ListViews! They are simply so bad implemented that you can go and get a coffee if you want to scroll to the last of just 100 items. The replacement called RecycleView couldn't be called stranger - please think about the users who are new to Kivy.

Kivy is completly useless for Desktop applications. A self made file chooser like this is not an option. This is really the killer. On the other hand Qt for Android is useless too.

So what? I would propose fewer magic and clearer layout handling which will bring more lines of code and therefore more implementation work, but at the end, it will save much time you need for fixing broken layouts... Thankg for you patience reading this and hopefully gives some ideas you could work on... Claudio

-- You received this message because you are subscribed to the Google Groups "Kivy users support" group. To unsubscribe from this group and stop receiving emails from it, send an email to kivy-users+...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.

[st...@btp.nl]

In addtion to thsirtman last paragraph we too use kivy professional to develop a large, serious gaming system, wich we deploy on many hundreds of systems and kivy allows us to develop stuff quickly and efficiently.

Sure it has its quirks but as someone who has developed software in gtk+ and qt for many years i assure you that those frameworks also have their quirks and weird stuff you need to get your head around.
I think you should perhaps aksed this list earlier when you encountered problems. Also o'reilly has a nice book about developing in kivy.

http://www.btp.nl/braintrainerplus-light/ (website is in dutch)

Regards,
Stas Zytkiewicz

[Claudio]

Thanks tshirtman for staying kind and patient on answering my problems and doubts... ;)

As professional software developer and system architect I am used to learn new frameworks or at least new librarys and with Qt I was pretty fast. The concept about signal / slots with the precompiler was a bit strange for me at the beginning, then I got it. I only needed some tutorials and examples on their web page and then I was able to do all my (complicated) GUIs pretty fast. So I thought I also get on Kivy pretty fast, but it was not the case. I really read everything I found on the "Getting started" pages, the API ref and checked all examples - but the logic was extremly different than I expected - that's why a was so slow. Somebody with a different approach is maybe more successfull than me (and also reads the docs with other soluthens in mind than me).

What surprises me the most from the answers from point #4 to #7 is this: first, you're using FloatLayouts and also you're saying all layouts have only an influence to just one sublevel! Is this a bug or a feature? So if you don't fetch the position of the button in our example, you can really draw everywhere on the screen? And about the FloatLayouts: I see some Kivy professionals always use the FloatLayouts - is this essential for surviving Kivy? In Qt I'm always using Box- and StackLayouts - but in Kivy there is so much unexpected behavior and this leads me to the conclusion that you should never use BoxLayouts - am I right? So depending on the widget itself - but also on the layout type size_hint/width/height/pos_hint/x/y does something or does nothing? How can you know that?

By the way, I also tried to calculate some positions  using the parnet's position, but I always run into a startup loop (cyclical behavior) so I got rid of it.

About ActionBars (#8): they must be in a very early development stage. You can add items to groups, but you can't clear them - beside many other strange things. I think they should be improved or removed at all. In combination with screen managers they're too evil.

About TextInput (#9): I needed a multiline basic text editor (r+w) on Android and that's one of the worst thing that can happen, I learned. First, the keyboard pops up and scrolls everything up, so you can't see the cursor any more (and you can't handle it). Then you fiddle around and the keyboard overlaps the text input and you can't see it at all. Very evil, very evil.

Well, thanks for beeing enough open minded for my criticism ;)
Claudio

[ZenCODE]

Having used many GUI frameworks, what is very different about kivy is that is relies upon bindings to update your GUI rather than specifying co-ordinates and positioning upfront. It's re-active. Usually, you specify x,y co-ordinates and widths/heights right from the start. That does not work with Kivy, because those dimensions are not yet determined. Your whole UI needs to be events based, as the specific dimensions are not yet known when your app is initialized....

I come from a Visual Basic background where you knew all those things upfront, so your drawings and co-ords were known upfront. As you do, I also felt kivy frustrating upfront because things don't behave as you expect them to. Every device is different, and if you want to cater for them, you cannot expect them to behave in a simplistic "It looks like this on my device, it should look the same on yours!". Devices are different and should be, have to be.

So, after many, many hours of labor, I realized that Kivy is incredibly forward thinking. Instead of relying of device or operating system specifics, it gives you and incredibly flexible and responsive way to handle all of these varied requirements. By binding to any screen width/height/pixel density/font density your device supports, kivy gives you more power and flexibility than any other framework I have personally seen.

Yes, it is not simple. But catering for thousands of modern devices that all run at different resolution and pixel devices in inherently complex. One can not just hope "What I see is what you should see." That is unrealistic, given your device is totally different from mine. Or am I just dumb?

If you want to present a user interface across multiple aspect ratios, pixel densities and font densities, you do actually need to think. Personally, I believe its' unrealistic to think you can just produce a User Interface that works in every context..

[C.D. MacEachern]

I have similar sentiments. Kivy promised so much, and mostly delivered, but in the end I had to abandon it because of the horrible experience with deploying cross-platform, and the lack of support from the community/documentation, which is a bit expected though considering it is a free product. I've cut my losses and rewrote the mobile version using Swift (no Android plans anymore) using XCode which was a fantastic experience. I still hold out hope that someday Python will finally figure out the issues with deploying binaries. I think the 'toga' project looks very promising, but I'm a bit jaded about these projects at the moment.

[Geekademy]

On 2017-10-12 07:30, C.D. MacEachern wrote:
> I have similar sentiments. Kivy promised so much, and mostly delivered, but in
> the end I had to abandon it because of the horrible experience with deploying
> cross-platform, and the lack of support from the community/documentation, which
> is a bit expected though considering it is a free product.

Indeed, you can get help here for trivial or RTFM issues, but as soon as you hit
a serious bug you are completely on your own. I've even tried to pay for help
but so far that has been unsuccessful.

It's a shame because if I were able to finish my project it could lead to the
creation of real Kivy jobs in the future. Some investment in this area (a
consulting business?) would do a lot to ensure/improve Kivy in the long term.


> I've cut my losses and rewrote the mobile version using Swift...

Unfortunately, I have many months of work ahead of me (backend as well) and so
while learning swift and kotlin would be fun, there are better ways I could be
spending my time.

[Beyonlo]

Did you used https://gitlab.com/kivymd/KivyMD 

That is a incridible project. I using that for Kivy applications. I think that need a official support from kivy, because is more beautiful than the default Kivy widgets.

Anyone are using that too?

Thanks,

Beyonlo

--
You received this message because you are subscribed to the Google Groups "Kivy users support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kivy-users+unsubscribe@googlegroups.com.

[CorwinSTP]

Not trying to offend the original poster, but I have made a really complex game for desktop with the help of Kivy. It may be surprising to hear that I also had no prior programming experience before making my game and Kivy actually made it easier to learn. I however do not use the Kivy KV file. I programmed everything solely through Python. Perhaps that makes it easier to use for desktop?

[Geekademy]

If only the hard issues could be fixed with a new theme! ;-)

[panisset...@gmail.com]

I am.

Beyonlo

To unsubscribe from this group and stop receiving emails from it, send an email to kivy-users+...@googlegroups.com.

[Beyonlo]

Hi!

Anyone know if KivyMD are active, because in the github the last commit was 8 months ago. That can means two things:

1. The project are not more active.

2. Project already mature and stable and do not more new develpments for now.

Anyone know about that?

Thanks

Beyonlo

To unsubscribe from this group and stop receiving emails from it, send an email to kivy-users+unsubscribe@googlegroups.com.

[Oon-Ee Ng]

On Wed, Nov 1, 2017 at 12:27 AM, Beyonlo <bey...@gmail.com> wrote:

Hi!

Anyone know if KivyMD are active, because in the github the last commit was 8 months ago. That can means two things:

1. The project are not more active.

2. Project already mature and stable and do not more new develpments for now.

Anyone know about that?

Thanks

Beyonlo

It's not 'active' in the sense of active development, but the individuals with push access have not disappeared. Lacking new issues etc. things are fairly stable. 

[Gabriel Pettier]

Hi, i'm sorry, got busy and completly forgot about this. Better late than never, hopefuly.

On Mon, Oct 09, 2017 at 03:08:49PM -0700, Claudio wrote: Thanks tshirtman for staying kind and patient on answering my problems and doubts... ;) As professional software developer and system architect I am used to learn new frameworks or at least new librarys and with Qt I was pretty fast. The concept about signal / slots with the precompiler was a bit strange for me at the beginning, then I got it. I only needed some tutorials and examples on their web page and then I was able to do all my (complicated) GUIs pretty fast. So I thought I also get on Kivy pretty fast, but it was not the case. I really read everything I found on the "Getting started" pages, the API ref and checked all examples - but the logic was extremly different than I expected - that's why a was so slow. Somebody with a different approach is maybe more successfull than me (and also reads the docs with other soluthens in mind than me).

I'm sorry if the doc failed you, yes, the logic is certainly different from other frameworks, and it can be hard if you are trying to map existing knowledge on it, maybe someone with experience with other framework should write "Kivy for people who know X" guides that outlines conceptual differences (in a positive way) and save time to these people, i'm not the best person to do that.

What surprises me the most from the answers from point #4 to #7 is this: first, you're using FloatLayouts and also you're saying all layouts have only an influence to just one sublevel! Is this a bug or a feature? So if you don't fetch the position of the button in our example, you can really draw everywhere on the screen? And about the FloatLayouts: I see some Kivy professionals always use the FloatLayouts - is this essential for surviving Kivy? In Qt I'm always using Box- and StackLayouts - but in Kivy there is so much unexpected behavior and this leads me to the conclusion that you should never use BoxLayouts - am I right? So depending on the widget itself - but also on the layout type size_hint/width/height/pos_hint/x/y does something or does nothing? How can you know that?

It's by design, yes, widgets can draw anywhere on the screen, Kivy widgets are conceptually very simple, a mix of an EvendDispatcher (providing the same thing as slots/events in qt) and a canvas, which is a very thin abstractuion over OpenGL, and these touch events bindings. It means widget can be/do almost anything, without needing any special magic. On the other hand, it requires to take care of a few things when designing a new widget, or nesting them. They don't contraint their children by default. Either on what touch they receive (any widget can react to any touch event anywhere on the screen), or where they display themselves. So when you create your tree, you need to constraint everything, Layouts certainly help for that, but you can also specify things using custom rules. FloatLayout is just the most flexible layout, when you want things to be able to overlap, or to be sparsely positionned, it's often the best solution, but BoxLayout and GridLayout are very important too, i use them all the time, i sometime use StackLayout, but much less often.

By the way, I also tried to calculate some positions using the parnet's position, but I always run into a startup loop (cyclical behavior) so I got rid of it.

Yeah, often it's much easier to use a FloatLayout, or maybe a RelativeLayout, which might be more like you would expect by default.

About ActionBars (#8): they must be in a very early development stage. You can add items to groups, but you can't clear them - beside many other strange things. I think they should be improved or removed at all. In combination with screen managers they're too evil.

Yes, maybe it should be removed, i do think kivy could do with less default widgets, most of my applications involves creating most widgets from scratch anyway, even Buttons, i most of the time recreate with ButtonBehavior and some other class depending on my current needs. Label, Image, Video, ScrollView and the Layouts are the important building blocks to me. RecycleView is also incredibly important in some situation, but that's a bit specific.

About TextInput (#9): I needed a multiline basic text editor (r+w) on Android and that's one of the worst thing that can happen, I learned. First, the keyboard pops up and scrolls everything up, so you can't see the cursor any more (and you can't handle it). Then you fiddle around and the keyboard overlaps the text input and you can't see it at all. Very evil, very evil. Well, thanks for beeing enough open minded for my criticism ;) Claudio Am Sonntag, 8. Oktober 2017 14:24:30 UTC+2 schrieb tshirtman:

Hello First, it seems there are quite fundamental things about kivy that you missed, which means either you didn't read the documentation, or we did a pretty bad job at explaining them, but i'm quite impressed that you could go through 3 projects without understanding them.

That's a weird thing to start on, it's really a convention, we have two events here, it's up to you to decide on which to bind, and if you change your mind, pretty easy to change. 2. Kv lang is inspired by yaml and by qml, sure, it's not exactly the same, but it's not completly out of nowhere. 3.

I'm pretty sure that's explained in the documenation, but i'll restate it here: app simplest of them all, always refer to your App instance. self always refer to the innermost widget you are into, look lines up until you find a widget class name, that's the widget you are talking about root always refer to the outermost widget you are into, look lines up until you find one that is not indented at all, that's the widget you are talking about Layouts manage the position of all their direct children, if you nest something in a widget, it's not affected anymore by the layout. Doing what you are asking for here can be easy: FloatLayout: Button: id: button size_hint: .5, .5 pos_hint: {'center': (.5, .5)} Image: source: 'images/image-loading.gif' size: button.size pos: button.pos # you can add another label at the top of it, if the image hides the button's text Label: text: button.text pos: button.pos size: button.size But you could also do your own ImageButton class, and use it as many time as you want ImageButton@ButtonBehavior+Image: # is an Image with a button behavior, has on_press/release, etc text: '' # add a label at the top to display text atop the image Label: text: root.text size: root.size pos: root.pos text_size: root.size

I pretty often refactor a specific widget into a rule, it's not very different from taking out python code and make it into a function, cut, paste, unindent as much as needed, add a "header" (here new widget name), and the parameters, then use it at the previous place… Not sure if your editor is getting in the way somehow, or if you have a more specific issue you want to share. 2. see #4 plus

Layouts use size_hint and pos_hint to manage children's size/pos automatically, so pos/size won't have any effect in a layout's children unless size_hint/pos_hint allows them to. Other widgets don't use size_hint/pos_hint, so only pos/size will have an effect

see the answer to #3, or give more details, in my experience Image is simple, but very flexible. 2. Can't answer here, because i don't use that, but that looks like an issue with scrolling, which delay touches, that's an issue with kivy i'm willing to concede, our default values for scroll_timeout and scroll_distance are far from perfect, but you can tweak them, and improve things a lot. 3. You might want to use a specific widget if you have large amount of text to display, although TextInput does allow scrolling, it does so differently from ScrollView, i would advice (if it's only for display), using a RecycleView. 4. ListView is deprecated for a good reason, it's developpment didn't go the way we intended, it's API doesn't allow for good performances, as you noted, it's now replaced by RecycleView, we strongly advise everybody to switch. RecycleView itself works a bit differently, but you just need to pass a list of dicts containing your data, and the widget that will display them, to your layout. I know there is only one example in the documentation, but it's a good starting point, and some experimentation should clarify things. If not, questions are always welcome. 5.

Kivy focuses on its own set of widgets, but sometime you want a native look, not a common UI on all platform, and it's fine, for these things, plyer offer some answers, and one of them is a FileChooser that uses the native platform one. You might want to have a look. Criticism is always welcome, maybe our concepts are flawed or maybe we need to better explain them. But i personally build kivy apps at work at quite a decent speed, and i see others able to do the same, what takes is time is usually bugs that have to be fixed or worked around, not the general logic of the framework. On Sat, Oct 07, 2017 at 01:43:27AM -0700, Claudio wrote:

I'm very impressed about what Python enthusiasts were able to build with this Kivy framework! The amount of features is huge and I like very much the possibility of splitting the functions and the layout description into different files. So I really appreciate the huge work which has been done over all the years. But after three projects I can tell you the following: if you want to waste very much time - use Kivy! It's the strangest framework I've ever seen in my long experience of GUI programming! Qt for Android is suprisingly stable but does not respect any Android style guides and also seems like an alien app on your phone. So the next try will be something more web-based like Flask or something similar. So here is a list of things I learned - just to give you a view "from outside" - I don't want to blame Kivy - maybe it challanges you to work on some points? Things are always the opposite way than you know it. For instance if you are used to implement on_press events, you should use on_release. The Kv langauage is the strangest thing you can imagine. It does not remind anything you already know. There is much magic around. It's by chance if you take the right way to address an ID or class: just try 'self' then 'root' then 'app' and at the end 'root.dispatch()'. There's no guide how you can get the right addressing except by googling hours. Layouts do not work like you know for instance from Qt. If you add an image to a label, it paints anywhere on screen - no matter what layout you have chosen. Once you think your GUI is pretty enough you can change anything in the Kv file and everything messes up. For instance if you have to many indentation and you try to extract it in a separate declaration you can start at zero with your GUI. It breaks your whole layout. Changing size_hint/width/height/pos_hint/x/y does most of the time nothing but if it does it breaks the whole layout. So you can spend hours for just placing an image on the top of an other widget. Image handling is very primitive - you will spend hours just to add an image to a button which also contains a text. One of the worst thing you can use are the ActionBars. Completly unexpected behavior and most of the items are undocumented. Try to add so many items to a group that it needs a scroll bar - you will regret it, because you can't press the buttons any more. Even worse is a simple multiline TextInput showing 25 kB of text: you can't even scroll the text. But the worst thing which can happen are ListViews! They are simply so bad implemented that you can go and get a coffee if you want to scroll to the last of just 100 items. The replacement called RecycleView couldn't be called stranger - please think about the users who are new to Kivy. Kivy is completly useless for Desktop applications. A self made file chooser like this is not an option. This is really the killer. On the other hand Qt for Android is useless too. So what? I would propose fewer magic and clearer layout handling which will bring more lines of code and therefore more implementation work, but at the end, it will save much time you need for fixing broken layouts... Thankg for you patience reading this and hopefully gives some ideas you could work on... Claudio

-- You received this message because you are subscribed to the Google Groups "Kivy users support" group. To unsubscribe from this group and stop receiving emails from it, send an email to kivy-users+...@googlegroups.com <javascript:>. For more options, visit https://groups.google.com/d/optout.

[Gabriel Pettier]

Sorry to read that. Yes, our android and ios build process can and should be improved, it's quite involved to maintain them, because google and apple do like to ship breaking updates now and then, and of course have no care about our use case (not blaming them), we need a more self-supportive community, users helping each others with that, and possibly helping us keeping up to date, or to somehow fund someone to work full time on that.

-- You received this message because you are subscribed to the Google Groups "Kivy users support" group. To unsubscribe from this group and stop receiving emails from it, send an email to kivy-users+...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.

[Gabriel Pettier]

I doubt not using kv makes anything easier, but glad to hear it's going well for you :D

On Sat, Oct 14, 2017 at 04:07:28PM -0700, CorwinSTP wrote:

Not trying to offend the original poster, but I have made a really complex game for desktop with the help of Kivy. It may be surprising to hear that I also had no prior programming experience before making my game and Kivy actually made it easier to learn. I however do not use the Kivy KV file. I programmed everything solely through Python. Perhaps that makes it easier to use for desktop? On Saturday, October 7, 2017 at 3:43:28 AM UTC-5, Claudio wrote:

I'm very impressed about what Python enthusiasts were able to build with this Kivy framework! The amount of features is huge and I like very much the possibility of splitting the functions and the layout description into different files. So I really appreciate the huge work which has been done over all the years. But after three projects I can tell you the following: if you want to waste very much time - use Kivy! It's the strangest framework I've ever seen in my long experience of GUI programming! Qt for Android is suprisingly stable but does not respect any Android style guides and also seems like an alien app on your phone. So the next try will be something more web-based like Flask or something similar. So here is a list of things I learned - just to give you a view "from outside" - I don't want to blame Kivy - maybe it challanges you to work on some points?

Things are always the opposite way than you know it. For instance if you are used to implement on_press events, you should use on_release.

The Kv langauage is the strangest thing you can imagine. It does not remind anything you already know.

There is much magic around. It's by chance if you take the right way to address an ID or class: just try 'self' then 'root' then 'app' and at the end 'root.dispatch()'. There's no guide how you can get the right addressing except by googling hours.

Layouts do not work like you know for instance from Qt. If you add an image to a label, it paints anywhere on screen - no matter what layout you have chosen.

Once you think your GUI is pretty enough you can change anything in the Kv file and everything messes up. For instance if you have to many indentation and you try to extract it in a separate declaration you can start at zero with your GUI. It breaks your whole layout.

Changing size_hint/width/height/pos_hint/x/y does most of the time nothing but if it does it breaks the whole layout. So you can spend hours for just placing an image on the top of an other widget.

Image handling is very primitive - you will spend hours just to add an image to a button which also contains a text.

One of the worst thing you can use are the ActionBars. Completly unexpected behavior and most of the items are undocumented. Try to add so many items to a group that it needs a scroll bar - you will regret it, because you can't press the buttons any more.

Even worse is a simple multiline TextInput showing 25 kB of text: you can't even scroll the text.

But the worst thing which can happen are ListViews! They are simply so bad implemented that you can go and get a coffee if you want to scroll to the last of just 100 items. The replacement called RecycleView couldn't be called stranger - please think about the users who are new to Kivy.

Kivy is completly useless for Desktop applications. A self made file chooser like this is not an option. This is really the killer. On the other hand Qt for Android is useless too.

So what? I would propose fewer magic and clearer layout handling which will bring more lines of code and therefore more implementation work, but at the end, it will save much time you need for fixing broken layouts... Thankg for you patience reading this and hopefully gives some ideas you could work on... Claudio

-- You received this message because you are subscribed to the Google Groups "Kivy users support" group. To unsubscribe from this group and stop receiving emails from it, send an email to kivy-users+...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.

[Joey daniel darko]

i also use kivyMD, this is a video sample of a working app 

https://www.youtube.com/watch?v=HEt15QIH-n8