<div class="gmail_quote">On Mon, Jan 16, 2012 at 10:19 PM, Marco Martin <span dir="ltr"><<a href="mailto:notmart@gmail.com">notmart@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Monday 16 January 2012, Mark wrote:<br>
> On Mon, Jan 16, 2012 at 9:40 PM, Marco Martin <<a href="mailto:notmart@gmail.com">notmart@gmail.com</a>> wrote:<br>
> > On Saturday 14 January 2012, Mark wrote:<br>
> > > Hi,<br>
> > ><br>
> > > This is just a mail to inform people that I'm working on auto<br>
> > > completion for QML.<br>
> > > Initially this was meant for my Breadcrumbbar that i'm also making for<br>
> ><br>
> > QML,<br>
> ><br>
> > > but after making the completion logic in C++ i figured that i might as<br>
> ><br>
> > well<br>
> ><br>
> > > make a generic version that can be used to autocomplete about anything.<br>
> > ><br>
> > > Work log (AutoComplete):<br>
> > > - C++ side auto completion: done<br>
> > > - Auto completion QML component (AutoCompleter): todo<br>
> > > - Ability to use "AutoCompleter" with TextField and a "dropdown" (where<br>
> ><br>
> > is<br>
> ><br>
> > > that QML plasma component?): todo<br>
> ><br>
> > comboboxes aren't supported at the moment, no<br>
> ><br>
> > good job on the autocompletition tough<br>
> > that should be provided transparently in textfield i think..<br>
> ><br>
> > Thanx, but remember that only the C++ side works at the moment, there is<br>
><br>
> nothing for it in QML.. Yet!<br>
><br>
> > still wondering how to do that, if try to stick with the desktop<br>
> > components implementation that can still change every day or trying<br>
> > something new altogether<br>
><br>
> I would go for an API like this (just doing it out of my head..):<br>
><br>
> AutoCompleter<br>
> {<br>
> id: autoCompleter<br>
> }<br>
><br>
> TextField<br>
> {<br>
> completer: autoCompleter<br>
> }<br>
<br>
</div></div>what is the advantage of declaring autocompleter independent and outside the<br>
textfield?<br>
<br>
(apart being close to impossible to make a c++ based component private :/)<br>
<div><div class="h5"><br></div></div></blockquote><div>I honestly don't know. I don't even know how to get that working. Kinda discovering that as i go..</div><div>I never made such a complex QML part before.</div>
<div><br></div><div>The idea however is to have one component wich holds the data (AutoCompleter) and another component to use that data (TextField). How else would you do it? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5">
<br>
> > > Work log (BreadcrumbBar):<br>
> > > - C++ side: 90% done (uses the C++ AutoComplete as described above<br>
> > > along with KIO)<br>
> > > - Binding it to QML: todo<br>
> > > - BreadcrumbBar qml side: 90% done (no auto completion in it yet and<br>
> ><br>
> > there<br>
> ><br>
> > > is no theme for it)<br>
> > ><br>
> > > My goal with the breadcrumbbar is to make it work exactly like the bar<br>
> > > in Dolphin. Only then written in QML and with fancy animations and<br>
> > > that is working really well at the moment ^_^<br>
> ><br>
> > what i am wondering a bit is the exact use case for it.<br>
> > since plasmoids are usually intended to be really simple uis, this seems<br>
> > quite<br>
> > complex.<br>
> ><br>
> > and i'm not saying that is not useful per se. i'm just wondering what was<br>
> > your<br>
> > use case.<br>
> ><br>
> > do you have a plasmoid that would use that? if so, should maybe be its<br>
> > private<br>
> > component for a while untilthere is a good use case to share it with<br>
> > others and thus put it in an extended components library..<br>
><br>
> You really want to know that do you..<br>
> Oke, this element is - at the moment - for pure selfish reasons. In the<br>
> longer term i want to make a very fancy QML only file browser (see it like<br>
> dolphin on steroids that themselves are on steroids ^_-) and for that i<br>
> need a breadcrumbbar. Please don't tell me "don't do it" or whatever. It's<br>
> just a technological idea i'm having that i'm trying to make piece by<br>
> piece.<br>
<br>
</div></div>nono, not telling to not do it, au contraire, could be a very interesting<br>
thing ;)<br>
<br></blockquote><div>I will :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
i'm just trying to see if kde-runtime is the right place for such a component,<br>
since its use case is mostly that application, and a full, real application<br>
even, as opposed to plasmoids that really really should stay simple (many of<br>
them are already way too much complicated i think)<br></blockquote><div><br></div><div>I think this is where we have a different point of view. I'm thinking in full blown awesome QML applications. There this component fits.</div>
<div>You're thinking in simple clean and lean plasmoids. There this component doesn't fit.</div><div><br></div><div>The question: what is the intended use of "plasmacomponents"? I think for both thus this one should be in there as well. In the longer term (like you say below) it certainly should be in. The question is just for the current ~year or so) Perhaps we should have a "plasmastagingcomponents" as well where components can go in and out all the time and move them to "plasmacomponents" when they have been proven to be useful. Nice idea?</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
so, i really think that at the moment that component should be used privately<br>
by the application and eventually made public when will come the time to have<br>
components for full desktop applications (and *will* come)<br>
that's not to discourage, is just about putting the things in the right place,<br>
because as soon you put an extra component in an import you commit maintaining<br>
it for the years to come, maintaining source compatibility as well (means for<br>
instance that you won't be able to rename anything, to remove a method, to<br>
change a property, for at least 2 years or so)<br>
<div class="im"><br>
> For example, i want to be able to make this a real app:<br>
> <a href="http://fc01.deviantart.net/fs70/f/2011/269/d/7/explorer_mockup_by_ap_graphi" target="_blank">http://fc01.deviantart.net/fs70/f/2011/269/d/7/explorer_mockup_by_ap_graphi</a><br>
</div>> k-d2nmjj4.png though<br>
<div class="im">> that has some usability issues ;)<br>
<br>
</div>has usability issues of course, is drawn really well tough ;) would be nice<br>
seeing experiments like that<br>
<div class="im"><br>
> But there is a usecase for it! Just look at kickoff-qml. That app is using<br>
> a breadcrumbbar and now we already have 2 apps with breadcrumbs and 2<br>
> different breadcrumbbar types: dolphin and kickoff-qml. Who knows how many<br>
<br>
</div>plasma widgets and qwidgets are designed and meant to be different.<br>
that's another reason why components for applications and plasmoids shouldn't<br>
mix.<br>
<br>
also, in kickof the breadcrumb bar should be much simpler than your use case i<br>
think (no kio support for instance)<br>
<div class="HOEnZb"><div class="h5"></div></div></blockquote></div><br><div>Ohh, but i can do something about that last part.</div><div>I think I can fairly easy make a "useKio" flag. If it's set to true it's the breadcrumbbar i intended, if set to false then the user must supply the data. Nice idea?</div>