Re: [yocto] [PATCHv2 0/8][eclipse-poky] Add target profile quick switch
Hi Jessica Zhang, Jessica wrote, On 24.06.2013 07:25: Hi Timo, For case 1, I think we probably should bring back the grey out option. In my opinion, it's more consistent. The property window should be the centralized place for user to setup the settings. The drop down list is for user to quickly toggle between the different settings. So the behavior should be: If there's no project specific settings, that option will be greyed out. I don't think it'll make it secondary as long as it's still visible. Once user 1st time check the project specific setting in the project properties window, we copy the prior profile settings as start point then the user can further customize if there's the need. Once a project has its own specific settings, the option will be enabled in the drop down list and the selection will be consistent between the drop down list selection and project properties settings. What do you think? I get your point. I'll kick out the last patch to restore the greyed out version. I tried to reproduce case 3. And I haven't been able to bring the menu to a state where two menu items are checked. I tried all sorts of combinations without success. Could you maybe tell me the exact steps on how you get this behaviour? However, when trying the different options I realized that there's a bug in the project preferences. Maybe you've already pointed it out and I didn't get it. But if you've configured a project specific profile and change to a target profile, when you enable the project specific profile again, your settings are lost. Instead the selected profile is copied all of the time, instead of only at the first time of configuration. I'll send a fix and a v3 of the menu with the greyed out menu item. Jessica -Original Message- From: Timo Mueller [mailto:m...@timomueller.eu] Sent: Sunday, June 23, 2013 1:36 AM To: Zhang, Jessica Cc: yocto@yoctoproject.org; Timo Mueller Subject: Re: [yocto] [PATCHv2 0/8][eclipse-poky] Add target profile quick switch Hi Jessica, Am 21.06.2013 23:47, schrieb Zhang, Jessica: Hi Timo, So what's the purpose of "Project Specific Settings", my > understanding is it's something that only local to project instead of > global name space, e.g. profile? Yes, that's the main idea. OK, I've played a little bit of toggling between profiles, and project specific setting and notice > the following behaviors that can be confusing: 1. As your preference that user can specify "project specific > settings". I've noticed for this case, if I haven't entered any > project specific settings via the preference wizard, it'll always > copy the profile settings prior to its selection, then in this case I > don't think it makes much sense since we already have the profiles to > cover all the settings That's independent of this patch set, right? The original idea behind copying the settings of the currently selected profile was to give the user a starting point for creating the project specific settings. The assumption was that the user most of the times only does small modifications to an existing profile. Sure, if the user doesn't alter the settings, the project specific ones match an already defined target profile. One difference remains, if he changes the target profile it will update all projects that use this profile. The project that is using it's own configuration won't be changed, although the settings are similar. An alternative to copying the inital settings would be to blank out the form, when the checkbox is checked. If the assumption is not correct and we think that this is easier to understand for the user, I'll provide a patch set changing this behaviour. 2. OK, now let's move to the case of that I do have explicit setup a > project specific settings in the project property view apply it and > exit the window. After that, in the drop down list, when I toggle > between the options, e.g. I have two profiles besides the project > specific settings, then every time after I made the selection and > check in the project properties view, the settings matches my > selection. So this is good and consistent behavior. 3. If inside the project properties window, I uncheck the "Use > project specific settings" box, and select a profile then apply the > changes close the window. Now in the drop down list I will see both > the "project specific setting" and the selected profile are selected. Then next time when I go back, and re-check "Use project specific > settings" box, my project specific setting will be gone, instead the > settings will show as my previous profile settings. That's a bug in my implementation. They should always be in sink as you explained in your second point. Overall, I think we still need to play a little bit more of different > setting selections via different approaches, some of the inconsistent > behavior can get user lost. Thanks, Jessica -Original Message- From: yocto-boun...@yoctoprojec
Re: [yocto] Documenting YP Development Environment in more detail
Hi Trever et al: > If I were writing a book about Yocto/OE, This is a project I am currently working on, a book about the Yocto Project. The goal is to enable readers to do practical projects with YP. As the subject matter for the project described in the book I have chosen a home automation project. Reason being, it interests me personally and it uses different devices such as a UI-less controller, remotes with touch screens etc. I have gotten a lot of feedback from the YP training class I have developed and been teaching for the Linux Foundation. I am putting this out here to solicit more feedback from the community on what you think a book on YP should include. For instance as an advanced topic I included a chapter on how to run YP on AWS EC2 and I will be adding Autobuilder to it too. > in the first chapter I would > have the readers build their own filesystem/kernel from scratch (I > can't decide if I would also have them build their own cross-compiler > from scratch or if I'd cheat and let them use crosstool-NG). I thought about that too but I found it distracting. It's like "let me show you the hard way with crosstool-ng and buildroot and then I show you a better way with YP." What I am doing though is an intro into Bitbake: how to use just Bitbake to build something. That proved valuable during the training classes. It's like a HelloWorld (and I published that before on this mailing list) introducing the concepts of Bitbake with it's layers, recipes, syntax etc. Cheers, Rudi ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCHv2 0/8][eclipse-poky] Add target profile quick switch
Hi Timo, For case 1, I think we probably should bring back the grey out option. In my opinion, it's more consistent. The property window should be the centralized place for user to setup the settings. The drop down list is for user to quickly toggle between the different settings. So the behavior should be: If there's no project specific settings, that option will be greyed out. I don't think it'll make it secondary as long as it's still visible. Once user 1st time check the project specific setting in the project properties window, we copy the prior profile settings as start point then the user can further customize if there's the need. Once a project has its own specific settings, the option will be enabled in the drop down list and the selection will be consistent between the drop down list selection and project properties settings. What do you think? Jessica -Original Message- From: Timo Mueller [mailto:m...@timomueller.eu] Sent: Sunday, June 23, 2013 1:36 AM To: Zhang, Jessica Cc: yocto@yoctoproject.org; Timo Mueller Subject: Re: [yocto] [PATCHv2 0/8][eclipse-poky] Add target profile quick switch Hi Jessica, Am 21.06.2013 23:47, schrieb Zhang, Jessica: > Hi Timo, > > So what's the purpose of "Project Specific Settings", my > understanding is > it's something that only local to project instead of > global name space, > e.g. profile? Yes, that's the main idea. > OK, I've played a little bit of > toggling between profiles, and project specific setting and notice > the > following behaviors that can be confusing: > > 1. As your preference that user can specify "project specific > settings". > I've noticed for this case, if I haven't entered any > project specific > settings via the preference wizard, it'll always > copy the profile > settings prior to its selection, then in this case I > don't think it makes > much sense since we already have the profiles to > cover all the settings That's independent of this patch set, right? The original idea behind copying the settings of the currently selected profile was to give the user a starting point for creating the project specific settings. The assumption was that the user most of the times only does small modifications to an existing profile. Sure, if the user doesn't alter the settings, the project specific ones match an already defined target profile. One difference remains, if he changes the target profile it will update all projects that use this profile. The project that is using it's own configuration won't be changed, although the settings are similar. An alternative to copying the inital settings would be to blank out the form, when the checkbox is checked. If the assumption is not correct and we think that this is easier to understand for the user, I'll provide a patch set changing this behaviour. > > 2. OK, now let's move to the case of that I do have explicit setup a > > project specific settings in the project property view apply it and > exit > the window. After that, in the drop down list, when I toggle > between the > options, e.g. I have two profiles besides the project > specific settings, > then every time after I made the selection and > check in the project > properties view, the settings matches my > selection. So this is good and > consistent behavior. > > 3. If inside the project properties window, I uncheck the "Use > project > specific settings" box, and select a profile then apply the > changes close > the window. Now in the drop down list I will see both > the "project > specific setting" and the selected profile are selected. > Then next time when I go back, and re-check "Use project specific > > settings" box, my project specific setting will be gone, instead the > > settings will show as my previous profile settings. That's a bug in my implementation. They should always be in sink as you explained in your second point. > > Overall, I think we still need to play a little bit more of different > > setting selections via different approaches, some of the inconsistent > > behavior can get user lost. > > Thanks, Jessica -Original Message- From: > yocto-boun...@yoctoproject.org > [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Timo Mueller > Sent: > Friday, June 21, 2013 5:45 AM To: yocto@yoctoproject.org Cc: > Timo Mueller Subject: [yocto] [PATCHv2 0/8][eclipse-poky] Add target > > profile quick switch > > From: Timo Mueller > > > Changes in v2: Handle error when project specific profile is not > > configured more gracefully. Instead of showing an error message the > > button is now greyed out. > > Patches 01..07 contain the implementation with the greyed out menu > button. > > After playing around with the two options discussed in the first > patch > series, I started to prefer inserting a different button in the > menu > allowing the user to quickly navigate
[yocto] Documenting YP Development Environment in more detail - user configuration
Hi, I am going to start throwing these diagrams out to the mailing list and see if I can get any feedback. This attached figure dives into user configuration. Any and all discussion, correction, suggestions are welcome. Scott >-Original Message- >From: Rifenbark, Scott M >Sent: Friday, June 21, 2013 1:22 AM >To: Paul Eggleton; Burton, Ross >Subject: user configuration > >Paul and Ross, > >Attached is a sample figure that focuses on "User Configuration." The >illustration attempts to reveal where user configuration data comes from >and what processes and user-driven commands are related to it. Right >now, BitBake is simply a box. > >If you can, give me some comments on this. I would like to hear on >level of detail as well as technical accuracy. > >Thanks, >Scott > >Scott Rifenbark >Intel Corporation >Yocto Project Documentation >503.712.2702 >503.341.0418 (cell) <>___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How NOT to include kernel image to the rootfs?
On 13-06-23 7:08 PM, Insop Song wrote: Hi, - Question "How NOT to include kernel image to the rootfs?" - Background In our application, we use u-boot to load kernel and rootfs from nand flash separately. I don't want to include kernel image inside /boot as I don't need it over there. I could untar the rootfs, remove, and tar it up again, but I would like to find a way within the yocto framework. I was not able to find a way by looking up the recipies and googling on this topic. Could any one help me? Have you tried clearing RDEPENDS_kernel-base ? From kernel.bbclass: # Allow machines to override this dependency if kernel image files are # not wanted in images as standard RDEPENDS_kernel-base ?= "kernel-image" Cheers, Bruce Thank you, Insop ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] linux-yocto-rt and cgroups
On 13-06-23 3:48 PM, Paul D. DeRocco wrote: I built core-image-base with Tom Zanussi's Cedartrail BSP for Dylan, which worked fine. (Thanks, Tom.) Then, I switched over to linux-yocto-rt, and it still worked fine. Then, I tried to switch to systemd, and it complains bitterly on startup that there is no cgroup support in the kernel. I'd like to use an RT kernel, so that I can squeeze out as many notes as possible (it's a musical instrument) before getting sound driver underruns. And I'd like to use systemd, so that it boots fast. Do I have to choose one or the other? Is there some reason cgroups are left out of linux-yocto-rt? If not, is there an easy way to put it back in, without becoming an expert in kernel configuration? There's no technical reason at all. In fact, pre 3.8 the -rt kernel used to inherit more of the standard kernel's configuration and hence enabled cgroups. In 3.8, we defined a new policy for the -rt kernel, that used parts of the standard kernel's configuration, but not all. We can definitely add functionality to this baseline, and I'll be adding more in the upcoming dev cycle for yocto 1.5. In the meantime you can enable it, and let me know how it goes. I can then update the -rt baseline config, knowing that someone else is testing it too. To enable it, create a linux-yocto_3.8.bbappend, and add: KERNEL_FEATURES_append = " features/cgroups/cgroups.scc" And you'll get the same cgroups config that you have with the standard linux-yocto kernel. Cheers, Bruce ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How NOT to include kernel image to the rootfs?
Hi, - Question "How NOT to include kernel image to the rootfs?" - Background In our application, we use u-boot to load kernel and rootfs from nand flash separately. I don't want to include kernel image inside /boot as I don't need it over there. I could untar the rootfs, remove, and tar it up again, but I would like to find a way within the yocto framework. I was not able to find a way by looking up the recipies and googling on this topic. Could any one help me? Thank you, Insop ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH v2] rpi-gpio: renamed from RPi-GPIO
On Wed, May 8, 2013 at 12:06 PM, Paul Barker wrote:
> Package names shouldn't contain capital letters.
>
> Signed-off-by: Paul Barker
> ---
> .../python/{RPi-GPIO => rpi-gpio}/don-t-install-setuptools.patch
> | 0
> recipes-devtools/python/{RPi-GPIO_0.2.0.bb => rpi-gpio_0.2.0.bb}
> | 0
> 2 files changed, 0 insertions(+), 0 deletions(-)
> rename recipes-devtools/python/{RPi-GPIO =>
> rpi-gpio}/don-t-install-setuptools.patch (100%)
> rename recipes-devtools/python/{RPi-GPIO_0.2.0.bb => rpi-gpio_0.2.0.bb}
> (100%)
>
> diff --git
> a/recipes-devtools/python/RPi-GPIO/don-t-install-setuptools.patch
> b/recipes-devtools/python/rpi-gpio/don-t-install-setuptools.patch
> similarity index 100%
> rename from recipes-devtools/python/RPi-GPIO/don-t-install-setuptools.patch
> rename to recipes-devtools/python/rpi-gpio/don-t-install-setuptools.patch
> diff --git
> a/recipes-devtools/python/RPi-GPIO_0.2.0.bbb/recipes-devtools/python/
> rpi-gpio_0.2.0.bb
> similarity index 100%
> rename from recipes-devtools/python/RPi-GPIO_0.2.0.bb
> rename to recipes-devtools/python/rpi-gpio_0.2.0.bb
> --
> 1.8.2.2
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
Merged. Thanks.
--
*Andrei Gherzan*
m: +40.744.478.414 | f: +40.31.816.28.12
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] linux-libc-headers-raspberrypi: Drop, its unneeded and bad practise
On Sun, Apr 21, 2013 at 6:21 PM, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> If we have this recipe, it means the whole armv6 (or whichever tune) is
> chosen depends
> on a machine specific recipe. This makes no sense as armX packages are
> meant to be
> machine independent.
>
> We've had this problem in other layers and it causes needed rebuilds of
> packages
> when you switch machines since the sstate checksums change. These headers
> are just part
> of the toolchain bootstrap process so "standard" kernel headers are fine.
> The kernel
> header version does need to be later of equal to the kernel version but
> we're fine in
> that regard since the core is on 3.8, the latest pi kernel is 3.6.
>
> There is nothing special about these headers so lets remove them and use
> the standard
> system provided recipe, avoding any rebuilds. I tested the various other
> recipes in
> the layer and there doesn't seem to be any dependency on these headers.
>
> Signed-off-by: Richard Purdie
> ---
> .../linux-libc-headers-raspberrypi_3.2.27.bb | 12
>
> 1 file changed, 12 deletions(-)
> delete mode 100644 recipes-kernel/linux-libc-headers/
> linux-libc-headers-raspberrypi_3.2.27.bb
>
> diff --git a/recipes-kernel/linux-libc-headers/
> linux-libc-headers-raspberrypi_3.2.27.bbb/recipes-kernel/linux-libc-headers/
> linux-libc-headers-raspberrypi_3.2.27.bb
> deleted file mode 100644
> index a5964ab..000
> --- a/recipes-kernel/linux-libc-headers/
> linux-libc-headers-raspberrypi_3.2.27.bb
> +++ /dev/null
> @@ -1,12 +0,0 @@
> -require recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> -
> -PR = "r0"
> -
> -PROVIDES = "linux-libc-headers"
> -RPROVIDES_${PN}-dev = "linux-libc-headers-dev"
> -RPROVIDES_${PN}-dbg = "linux-libc-headers-dbg"
> -
> -SRCREV = "10182a3bc434b27740f81c2b836a1af943060241"
> -SRC_URI = "git://
> github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.2.27 \
> - "
> -S = "${WORKDIR}/git"
> --
> 1.7.10.4
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
Sorry for missing out your patch. Please include "[meta-rapberrypi]" in
your subject prefix next time.
Thank you for you contribution. Patch merged.
--
*Andrei Gherzan*
m: +40.744.478.414 | f: +40.31.816.28.12
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] linux-raspberrypi: Fix i2c issues
On Sun, Apr 21, 2013 at 5:23 PM, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> I was having intermittent i2c issues on the device until I applied this
> kernel patch
> which I found online.
>
> Signed-off-by: Richard Purdie
> ---
> .../sl030raspberrypii2ckernel.patch| 32
>
> recipes-kernel/linux/linux-raspberrypi_3.2.27.bb |1 +
> recipes-kernel/linux/linux-raspberrypi_3.6.11.bb |1 +
> 3 files changed, 34 insertions(+)
> create mode 100644
> recipes-kernel/linux/linux-raspberrypi/sl030raspberrypii2ckernel.patch
>
> diff --git
> a/recipes-kernel/linux/linux-raspberrypi/sl030raspberrypii2ckernel.patch
> b/recipes-kernel/linux/linux-raspberrypi/sl030raspberrypii2ckernel.patch
> new file mode 100644
> index 000..8534ecb
> --- /dev/null
> +++
> b/recipes-kernel/linux/linux-raspberrypi/sl030raspberrypii2ckernel.patch
> @@ -0,0 +1,32 @@
> +Fix i2c timing errors.
> +
> +When Transmitting: Make SDA valid quarter of a cycle after the falling
> edge of SCL.
> +When Receiving: Sample SDA Quarter of a cycle after the rising edge of
> SCL.
> +
> +Upstream-Status: Pending
> +
> +RP 2013/04/21
> +
> +Index: git/drivers/i2c/busses/i2c-bcm2708.c
> +===
> +--- git.orig/drivers/i2c/busses/i2c-bcm2708.c 2013-01-06
> 17:15:00.754954587 +
> git/drivers/i2c/busses/i2c-bcm2708.c 2013-01-06
> 17:50:09.794905741 +
> +@@ -150,6 +150,7 @@
> + unsigned long bus_hz;
> + u32 cdiv;
> + u32 c = BSC_C_I2CEN | BSC_C_INTD | BSC_C_ST | BSC_C_CLEAR_1;
> ++ u32 cdel;
> +
> + bus_hz = clk_get_rate(bi->clk);
> + cdiv = bus_hz / baudrate;
> +@@ -163,6 +164,10 @@
> + bcm2708_wr(bi, BSC_A, bi->msg->addr);
> + bcm2708_wr(bi, BSC_DLEN, bi->msg->len);
> + bcm2708_wr(bi, BSC_C, c);
> ++
> ++ cdel = (cdiv / 4) & 0x;
> ++ cdel = cdel << 16 | cdel;
> ++ bcm2708_wr(bi, BSC_DEL, cdel);
> + }
> +
> + static irqreturn_t bcm2708_i2c_interrupt(int irq, void *dev_id)
> diff --git
> a/recipes-kernel/linux/linux-raspberrypi_3.2.27.bbb/recipes-kernel/linux/
> linux-raspberrypi_3.2.27.bb
> index c7a12e6..a68186b 100644
> --- a/recipes-kernel/linux/linux-raspberrypi_3.2.27.bb
> +++ b/recipes-kernel/linux/linux-raspberrypi_3.2.27.bb
> @@ -8,6 +8,7 @@ PV_append = "+git${SRCREV}"
>
> SRCREV = "10182a3bc434b27740f81c2b836a1af943060241"
> SRC_URI = "git://
> github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.2.27 \
> + file://sl030raspberrypii2ckernel.patch \
>"
> S = "${WORKDIR}/git"
>
> diff --git
> a/recipes-kernel/linux/linux-raspberrypi_3.6.11.bbb/recipes-kernel/linux/
> linux-raspberrypi_3.6.11.bb
> index caee7f2..07b0ae8 100644
> --- a/recipes-kernel/linux/linux-raspberrypi_3.6.11.bb
> +++ b/recipes-kernel/linux/linux-raspberrypi_3.6.11.bb
> @@ -8,6 +8,7 @@ PV_append = "+git${SRCREV}"
>
> SRCREV = "31a951046155b27361127d9cf85a1f58719fe9b3"
> SRC_URI = "git://
> github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.6.y \
> + file://sl030raspberrypii2ckernel.patch \
>"
> S = "${WORKDIR}/git"
>
> --
> 1.7.10.4
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
Thank you. Patch merged.
--
*Andrei Gherzan*
m: +40.744.478.414 | f: +40.31.816.28.12
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] linux-yocto-rt and cgroups
I built core-image-base with Tom Zanussi's Cedartrail BSP for Dylan, which worked fine. (Thanks, Tom.) Then, I switched over to linux-yocto-rt, and it still worked fine. Then, I tried to switch to systemd, and it complains bitterly on startup that there is no cgroup support in the kernel. I'd like to use an RT kernel, so that I can squeeze out as many notes as possible (it's a musical instrument) before getting sound driver underruns. And I'd like to use systemd, so that it boots fast. Do I have to choose one or the other? Is there some reason cgroups are left out of linux-yocto-rt? If not, is there an easy way to put it back in, without becoming an expert in kernel configuration? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCHv2 0/8][eclipse-poky] Add target profile quick switch
Hi Jessica, Am 21.06.2013 23:47, schrieb Zhang, Jessica: Hi Timo, > > So what's the purpose of "Project Specific Settings", my > understanding is it's something that only local to project instead of > global name space, e.g. profile? Yes, that's the main idea. OK, I've played a little bit of > toggling between profiles, and project specific setting and notice > the following behaviors that can be confusing: > > 1. As your preference that user can specify "project specific > settings". I've noticed for this case, if I haven't entered any > project specific settings via the preference wizard, it'll always > copy the profile settings prior to its selection, then in this case I > don't think it makes much sense since we already have the profiles to > cover all the settings That's independent of this patch set, right? The original idea behind copying the settings of the currently selected profile was to give the user a starting point for creating the project specific settings. The assumption was that the user most of the times only does small modifications to an existing profile. Sure, if the user doesn't alter the settings, the project specific ones match an already defined target profile. One difference remains, if he changes the target profile it will update all projects that use this profile. The project that is using it's own configuration won't be changed, although the settings are similar. An alternative to copying the inital settings would be to blank out the form, when the checkbox is checked. If the assumption is not correct and we think that this is easier to understand for the user, I'll provide a patch set changing this behaviour. > 2. OK, now let's move to the case of that I do have explicit setup a > project specific settings in the project property view apply it and > exit the window. After that, in the drop down list, when I toggle > between the options, e.g. I have two profiles besides the project > specific settings, then every time after I made the selection and > check in the project properties view, the settings matches my > selection. So this is good and consistent behavior. > > 3. If inside the project properties window, I uncheck the "Use > project specific settings" box, and select a profile then apply the > changes close the window. Now in the drop down list I will see both > the "project specific setting" and the selected profile are selected. > Then next time when I go back, and re-check "Use project specific > settings" box, my project specific setting will be gone, instead the > settings will show as my previous profile settings. That's a bug in my implementation. They should always be in sink as you explained in your second point. > Overall, I think we still need to play a little bit more of different > setting selections via different approaches, some of the inconsistent > behavior can get user lost. > > Thanks, Jessica -Original Message- From: > yocto-boun...@yoctoproject.org > [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Timo Mueller > Sent: Friday, June 21, 2013 5:45 AM To: yocto@yoctoproject.org Cc: > Timo Mueller Subject: [yocto] [PATCHv2 0/8][eclipse-poky] Add target > profile quick switch > > From: Timo Mueller > > Changes in v2: Handle error when project specific profile is not > configured more gracefully. Instead of showing an error message the > button is now greyed out. > > Patches 01..07 contain the implementation with the greyed out menu > button. > > After playing around with the two options discussed in the first > patch series, I started to prefer inserting a different button in the > menu allowing the user to quickly navigate to the project preferences > instead of just greying it out. I've added this in the last patch of > the series, so you can compare yourself. > > From original cover letter if a user wants to change the used > target profile of a project he currently has to open the project > preferences. This can be tedious if he has to switch the profile > often. > > This is a small addition which allows the user to quickly switch the > used target profile of a project. Instead of having to open the > project preferences the user can select the project in the navigator > and then choose the desired target profile from a drop-down menu in > the toolbar or from the project menu. > > 01: Small i18n fix 02..04: Refactoring the project specific utils > 05..06: Introduce the target profile toolbar switch 07: Adds the > target profile switch to the project menu 08: Experimental: Add > button to open project preferences > > Best regards, Timo Thanks, for the input. I'll fix the bug and send a v3. Best regards, Timo ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
