[SailfishDevel] Solved: Re: Dialog/ListView/Menu/Search

2020-01-04 Thread Thomas Tanghus
On Saturday, 4 January 2020 17.54.19 CET you wrote:
> How about this?
> 
> Dialog {
>  SilicaListView {
>  anchors.fill: parent
>  PullDownMenu { /* MenuItems */ }
>  header: Column {
>  width: parent.width
>  DialogHeader {
>  title: "Title"
>  }
>  SearchField {
>  width: parent.width
>  }
>  }
>  }
> }

Yes (below), but not with "width: parent.width" in the header column, which 
turned out to be crucial to have. If not the header didn't show at all. 
Thanks! Now I will make that repo read-only and save it for eternity ;)

The only practical issue here, is that the search field and the menu 
indicator are hidden behind the header until you scroll back, meaning that 
you could scroll all the way to the end of the list and back, before you 
noticed you could search instead. But that can probably be fixed with some 
top margin.
 
> > 
> > or:
> > 
> > Dialog {
> >  SilicaListView {
> >  PullDownMenu { /* MenuItems */ }
> >  header: Column {
> >   DialogHeader {}
> >   SearchField {}
> >  }
> >  }
> > }
> > 
> > Neither works, but as coderus wrote to me in a PR 4-5 years ago, I do
> > weird stuff ;)
> > 
> > I could write all the variations I've tried, but that would just be a
> > parade of more weird stuff with variations over missing or misplaced
> > header, menu, search field or list.
> > 
> > 
> > ___
> > SailfishOS.org Devel mailing list
> > To unsubscribe, please send a mail to
> > devel-unsubscr...@lists.sailfishos.org


-- 
Med venlig hilsen / Best regards

Thomas Tanghus

A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?


signature.asc
Description: This is a digitally signed message part.
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] Dialog/ListView/Menu/Search

2020-01-04 Thread Slava Monich

How about this?

Dialog {
SilicaListView {
anchors.fill: parent
PullDownMenu { /* MenuItems */ }
header: Column {
width: parent.width
DialogHeader {
title: "Title"
}
SearchField {
width: parent.width
}
}
}
}


I must be possible to do, but maybe my head is just wired wrong - well, I do
have that one paper already, so... :D

How to have a SilicaListView with a SearchField inside a Dialog with a
DialogHeader and a menu, where the SearchField is below the DialogHeader,
the list starts below both?

Every even semi-logical way to do this ends up, for me at least, with an
unholy mess.

What for me would seem logical is be a variation of:

Dialog {
 SilicaListView {
 PullDownMenu { /* MenuItems */ }
 header: DialogHeader {
 id: dialogHeader
 }
 SearchField {
 parent: dialogHeader.extraContent
 }
 }
}

or:

Dialog {
 SilicaListView {
 PullDownMenu { /* MenuItems */ }
 header: Column {
  DialogHeader {}
  SearchField {}
 }
 }
}

Neither works, but as coderus wrote to me in a PR 4-5 years ago, I do weird
stuff ;)

I could write all the variations I've tried, but that would just be a parade
of more weird stuff with variations over missing or misplaced header, menu,
search field or list.


___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] Dialog/ListView/Menu/Search

2020-01-04 Thread Thomas Tanghus
On Saturday, 4 January 2020 16.10 Thomas Tanghus wrote:
> Yes. Annoyingly DialogHeader.extraContent doesn't work like e.g.
> ListView.header/footer, so the above was how I tried.

Forgot to write that it resulted in the search field being *inside* the 
header, which is somewhat logical, but not what I was aiming for.

-- 
Med venlig hilsen / Best regards

Thomas Tanghus

A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?


signature.asc
Description: This is a digitally signed message part.
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] Dialog/ListView/Menu/Search

2020-01-04 Thread Thomas Tanghus
On Saturday, 4 January 2020 16.04 Michael Fuchs wrote:
> did you try extraContent?
 
> > Dialog {
> > SilicaListView {
> > PullDownMenu { /* MenuItems */ }
> > header: DialogHeader {
> > id: dialogHeader
> > }
> > SearchField {
> > parent: dialogHeader.extraContent
> > }
> > }
> > 

Yes. Annoyingly DialogHeader.extraContent doesn't work like e.g. 
ListView.header/footer, so the above was how I tried.

-- 
Med venlig hilsen / Best regards

Thomas Tanghus

A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?


signature.asc
Description: This is a digitally signed message part.
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] Dialog/ListView/Menu/Search

2020-01-04 Thread Michael Fuchs
Hi,

did you try extraContent?

https://sailfishos.org/develop/docs/silica/qml-sailfishsilica-sailfish-silica-dialogheader.html/#extraContent-prop

lG, Michael.

On Samstag, 4. Jänner 2020 16:00:29 CET Thomas Tanghus wrote:
> I must be possible to do, but maybe my head is just wired wrong - well, I do
> have that one paper already, so... :D
> 
> How to have a SilicaListView with a SearchField inside a Dialog with a
> DialogHeader and a menu, where the SearchField is below the DialogHeader,
> the list starts below both?
> 
> Every even semi-logical way to do this ends up, for me at least, with an
> unholy mess.
> 
> What for me would seem logical is be a variation of:
> 
> Dialog {
> SilicaListView {
> PullDownMenu { /* MenuItems */ }
> header: DialogHeader {
> id: dialogHeader
> }
> SearchField {
> parent: dialogHeader.extraContent
> }
> }
> }
> 
> or:
> 
> Dialog {
> SilicaListView {
> PullDownMenu { /* MenuItems */ }
> header: Column {
>  DialogHeader {}
>  SearchField {}
> }
> }
> }
> 
> Neither works, but as coderus wrote to me in a PR 4-5 years ago, I do weird
> stuff ;)
> 
> I could write all the variations I've tried, but that would just be a parade
> of more weird stuff with variations over missing or misplaced header, menu,
> search field or list.



___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

[SailfishDevel] Dialog/ListView/Menu/Search

2020-01-04 Thread Thomas Tanghus
I must be possible to do, but maybe my head is just wired wrong - well, I do 
have that one paper already, so... :D

How to have a SilicaListView with a SearchField inside a Dialog with a 
DialogHeader and a menu, where the SearchField is below the DialogHeader, 
the list starts below both?

Every even semi-logical way to do this ends up, for me at least, with an 
unholy mess.

What for me would seem logical is be a variation of:

Dialog {
SilicaListView {
PullDownMenu { /* MenuItems */ }
header: DialogHeader {
id: dialogHeader
}
SearchField {
parent: dialogHeader.extraContent
}
}
}

or:

Dialog {
SilicaListView {
PullDownMenu { /* MenuItems */ }
header: Column {
 DialogHeader {}
 SearchField {}
}
}
}

Neither works, but as coderus wrote to me in a PR 4-5 years ago, I do weird 
stuff ;)

I could write all the variations I've tried, but that would just be a parade 
of more weird stuff with variations over missing or misplaced header, menu, 
search field or list.

-- 
Med venlig hilsen / Best regards

Thomas Tanghus

A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?


signature.asc
Description: This is a digitally signed message part.
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] Flatpak for Sailfish

2020-01-04 Thread rinigus
Excellent! If something in kernel config is missing, I expect that you
could use Xperia 10 as a base to check the settings or for Xperia XZ2 used
by me at
https://github.com/sailfishos-sony-tama/android_kernel_sony_msm/blob/hybris-sony-aosp-9.0.0-4.9-tama-sony/arch/arm64/configs/aosp_tama_akari_defconfig

Rinigus

On Sat, Jan 4, 2020 at 12:47 AM Adam Pigg  wrote:

> Ill build it on mido and try it out, thanks!
>
> On Fri, 3 Jan 2020 at 22:45, rinigus  wrote:
>
>> Hi,
>>
>> I have submitted PR to libhybris allowing to use Flatpak on hybris
>> devices with the same version serving its main purpose and inside Flatpak
>> sandbox: https://github.com/libhybris/libhybris/pull/433.
>>
>> As soon as your device has such libhybris, you could
>>
>> - use https://build.merproject.org/project/show/home:rinigus:flatpak to
>> install flatpak, flatpak-runner
>> - run flatpak-extension-hybris to generate Flatpah hybris extension at
>> user nemo's home (run as nemo)
>> - install flatpak apps, see instructions at Flathub on how to do it
>> - run them using flatpak-runner
>>
>> Many things don't work, but would be faster to get it fixed together with
>> other devs.
>>
>> Cheers.
>>
>> Rinigus
>>
>> On Fri, Jan 3, 2020 at 12:18 AM rinigus  wrote:
>>
>>> Hi,
>>>
>>> just finished the first version of a wrapper for 'flatpak run' command
>>> as well, available at https://github.com/rinigus/flatpak-runner . Its
>>> based on qxcompositor and it opens new Wayland server before running an
>>> application, all explained in README. Device rotation is supported and
>>> should be followed.
>>>
>>> So, as it is:
>>>
>>> - we have to resolve libhybris linker issue to make it possible to
>>> distribute.
>>> - keyboard is not supported currently. At present, app has to have
>>> qtvirtualkeyboard support added as in
>>> https://doc.qt.io/qt-5/qtvirtualkeyboard-deployment-guide.html#creating-inputpanel
>>> .
>>> - only single-window apps are working well, such as QML developed for
>>> mobile
>>> - no sound so far
>>> - probably many other things are missing, haven't bumped into them.
>>>
>>> Essentially, we will have access to the latest Qt, but would have to
>>> write apps for this use. Fortunately, it all goes along SFOS programming
>>> and should be simple to convert later to Silica, when/if it catches up with
>>> Qt versions.
>>>
>>> I guess we can get better integration after it will be simple to install
>>> on other devices and start using it by others.
>>>
>>> Cheers,
>>>
>>> Rinigus
>>>
>>> On Wed, Jan 1, 2020 at 5:25 PM rinigus  wrote:
>>>
 Hi,

 wait a bit, I may have a way to simplify setup. Few days ago, after
 discussion on IRC, I found a way around disappearance of the window when
 wrapped into qxcomposer. So, that blocker is over now. Which means that we
 will be able to craft apps using the latest Qt available in Flatpaks.

 Currently, I am looking into

 - how we can use regular hybris
 - making a wrapper similar to qxcomposer for Flatpaks.

 Shouldn't take too long for an update on status.

 Cheers,

 Rinigus

 On Wed, Jan 1, 2020 at 4:55 PM  wrote:

> Could you elaborate on:
> > libhybris compiled with specification of default
> hybris-ld-library-path,
> > content of libexec/droid-hybris added with GL extension.
> Is that libhybris build available (and safe to run on main device, or
> should I dig out my j1)?
> Also not sure what added with GL extension means? Having a browser
> that uses up to date webengine would be awesome.
>
> Thanks and happy new year!
> szopin
>
> On Sunday, 29 December 2019, rinigus wrote:
> > Hi,
> >
> > I would have preferred to stay away from discussion on why do we
> need/not
> > need Flatpak on SFOS. But I guess I have to take it as the one
> working on
> > making it possible.
> >
> > Native apps rely on the libs allowed in the Store and bundle the
> rest of
> > them. I presume OSM Scout Server and Pure Maps are exceptions, but
> they are
> > built around almost 20 libs bundled with the application and
> compiled with
> > newer gcc than the one on the platform. If I would have continued to
> > provide OSM Scout Server via the official Store, I'd have to bundle
> > libsystemd as well - something that I found was crossing a line for
> me. So,
> > any security issue in those bundled libs would be propagated the
> same way
> > as with the Flatpak. I admit that its way less libs than distributed
> via
> > Flatpak. However, in the case of Flatpak, apps are provided on the
> top of
> > "runtimes" with the app including everything which is extending the
> runtime
> > to make it work. So, in case of OSM Scout Server and Pure Maps, their
> > Flatpaks do include some libs as well. Those runtimes are updated.
> Now, I
> > am not in position to say whether its