Implement Spark SkinnableDataContainer, reconfigure DataGroup, adjust List, and add SelfItemRendererInitializer

Implemented Spark SkinnableDataContainer, which is basically a combination of DataGroup, List, and SkinnableContainer.

Should use with DataGroup fix in #966 (not included in this pull request).

Reconfigured CSS of DataGroup to implement more proper behavior.  For example, when DataGroup.itemRender = null, it can by default render VGroup and such.  It can also take different layouts.  The old CSS for DataGroup, which was List-oriented, has been copied to VirtualVDataGroup (and List adjusted).  Adjusted NonVirtualHDataGroup (used by TabBar) and commented out NonVirtualVDataGroup (not used).

Added SelfItemRendererInitializer (+ SelfItemRenderer) to render UIComponent objects, such as VGroup and everything else.

Moved public var dataGroup:DataGroup; from SkinnableComponent to ListBase.

There are various existing layout bugs in components, and those are still reflected in DataGroup / SkinnableDataContainer, of course.

While DataGroup is laying out subcontainers very well, SkinnableDataContainer is not.  For many uses, you can work around by using "DataGroup" instead of "SkinnableDataContainer" (the MXML, for example, stays the same, with the dataProvider and such).  But of course it would be nice to get SkinnableDataContainer working properly.  SkinnableContainer does not have the same issue (though it has other issues).  Not sure if List has the issue.

While we have a growing list of pages in the help docs that detail the
features of Jewel components and how to use them, we have nothing yet for
Spark components. I can create a folder for such pages, but will need help
populating the pages, if people feel this would be useful.
I have created the folder and a page for SkinnableDataContainer [1], and
perhaps @estanglerbm could take a stab at populating it. If you or someone
can dump in the technical information, I can help with pulling the
text together so it is useful.
Andrew

https://github.com/apache/royale-docs/blob/master/component-sets/spark/skinnable-data-container
On Wed, Dec 9, 2020 at 1:31 AM estanglerbm<EMAIL_ADDRESS>wrote:

Implemented Spark SkinnableDataContainer, which is basically a
combination of DataGroup, List, and SkinnableContainer.
Should use with DataGroup fix in #966
https://github.com/apache/royale-asjs/pull/966 (not included in this
pull request).
Reconfigured CSS of DataGroup to implement more proper behavior. For
example, when DataGroup.itemRender = null, it can by default render VGroup
and such. It can also take different layouts. The old CSS for DataGroup,
which was List-oriented, has been copied to VirtualVDataGroup (and List
adjusted). Adjusted NonVirtualHDataGroup (used by TabBar) and commented out
NonVirtualVDataGroup (not used).
Added SelfItemRendererInitializer (+ SelfItemRenderer) to render
UIComponent objects, such as VGroup and everything else.
Moved public var dataGroup:DataGroup; from SkinnableComponent to
ListBase.
There are various existing layout bugs in components, and those are
still reflected in DataGroup / SkinnableDataContainer, of course.
While DataGroup is laying out subcontainers very well,
SkinnableDataContainer is not. For many uses, you can work around by using
"DataGroup" instead of "SkinnableDataContainer" (the MXML, for example,
stays the same, with the dataProvider and such). But of course it would be
nice to get SkinnableDataContainer working properly. SkinnableContainer
does not have the same issue (though it has other issues). Not sure if List
has the issue.

You can view, comment on, or merge this pull request online at:
https://github.com/apache/royale-asjs/pull/992
Commit Summary

Implement Spark SkinnableDataContainer, reconfigure DataGroup,
adjust List, and add SelfItemRendererInitializer.

File Changes

M frameworks/projects/SparkRoyale/src/main/resources/defaults.css
https://github.com/apache/royale-asjs/pull/992/files#diff-b058f3be2e770f5f03bdbf1fd8631e79adfc2d3aa2323efe88916c52b69613dc
(39)
M
frameworks/projects/SparkRoyale/src/main/resources/spark-royale-manifest.xml
https://github.com/apache/royale-asjs/pull/992/files#diff-72e16eca8e57cbb8eaa03e676ad814dd016e9ad33d8c76ce239e97fe54cad543
(4)
M
frameworks/projects/SparkRoyale/src/main/royale/SparkRoyaleClasses.as
https://github.com/apache/royale-asjs/pull/992/files#diff-1b34adf23801758fc843cf90ef7a2123ca92c9e494f0d685a6679656fcbd60cf
(2)
M
frameworks/projects/SparkRoyale/src/main/royale/spark/components/SkinnableDataContainer.as
https://github.com/apache/royale-asjs/pull/992/files#diff-bfa76aa100f9593cd4be40e744ce7a65dd9bf7cf6e8c44f97789eb632528b90d
(285)
A
frameworks/projects/SparkRoyale/src/main/royale/spark/components/VirtualVDataGroup.as
https://github.com/apache/royale-asjs/pull/992/files#diff-9740e8d3f55a6d41a416ad34efa1afbba42b36939053d272bbe731abea180089
(49)
A
frameworks/projects/SparkRoyale/src/main/royale/spark/components/beads/SelfItemRenderer.as
https://github.com/apache/royale-asjs/pull/992/files#diff-aa564321d9d6e39355cc4e6fa99182bfcd649645e311096665a03ce748f698d8
(52)
A
frameworks/projects/SparkRoyale/src/main/royale/spark/components/beads/SelfItemRendererInitializer.as
https://github.com/apache/royale-asjs/pull/992/files#diff-fdb3949acf88b32777656e1221c073d21d6db14e1432cf6c82f5e4169468bc81
(88)
A
frameworks/projects/SparkRoyale/src/main/royale/spark/components/beads/SkinnableDataContainerView.as
https://github.com/apache/royale-asjs/pull/992/files#diff-821a40dbf63ef5d1759a045aae0a69c012a867d0f86aab806041ced81272fa77
(143)
A
frameworks/projects/SparkRoyale/src/main/royale/spark/components/beads/SparkDataContainerView.as
https://github.com/apache/royale-asjs/pull/992/files#diff-90c32615b7872832dfda0902f94c8e29096161b5b7665f0e829df8e7b0be08c2
(130)
M
frameworks/projects/SparkRoyale/src/main/royale/spark/components/beads/SparkSkinScrollingViewport.as
https://github.com/apache/royale-asjs/pull/992/files#diff-e0d51daa09abae2ac194c95e738b0fd4937313271b8df849e87623651b8acf63
(1)
M
frameworks/projects/SparkRoyale/src/main/royale/spark/components/beads/SparkSkinViewport.as
https://github.com/apache/royale-asjs/pull/992/files#diff-79ec26253bd2a875e77ccec370de53afc64bc98848518fd059f8a8c0ee36ac73
(40)
M
frameworks/projects/SparkRoyale/src/main/royale/spark/components/supportClasses/ListBase.as
https://github.com/apache/royale-asjs/pull/992/files#diff-62fa3efbc8bf3cea3106e1f9c8825a226705a326ff80584464f6f94f2c1f0556
(18)
M
frameworks/projects/SparkRoyale/src/main/royale/spark/components/supportClasses/SkinnableComponent.as
https://github.com/apache/royale-asjs/pull/992/files#diff-97aef87c0839705178c77b1f4e419d1c445ce2a4e5cd3af3272ad3e19f96c6b6
(13)
M
frameworks/projects/SparkRoyale/src/main/royale/spark/layouts/HorizontalLayout.as
https://github.com/apache/royale-asjs/pull/992/files#diff-6e8f3e36da690addd45ab5729c2a1d37c9a9d87c1ec39953474be9a394f67613
(2)
M
frameworks/projects/SparkRoyale/src/main/royale/spark/layouts/VerticalLayout.as
https://github.com/apache/royale-asjs/pull/992/files#diff-a002af10900ff1d1ba66dfa0dc8d74cdc0cb44f55a9c06cd9aaee45971cde171
(2)
M
frameworks/projects/SparkRoyale/src/main/royale/spark/layouts/supportClasses/SparkLayoutBead.as
https://github.com/apache/royale-asjs/pull/992/files#diff-8e2e445d1f850f16eba2c14dfa1b7d42e30324ff5f3a2922cd7216f1704b55be
(3)

Patch Links:

https://github.com/apache/royale-asjs/pull/992.patch
https://github.com/apache/royale-asjs/pull/992.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/apache/royale-asjs/pull/992, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AC3RFXJSZ7AVPYDNNTYAIALST4DURANCNFSM4US7BRFA
.

--
Andrew Wetmore
Technical Writer-Editor
Infra
Apache Software Foundation
<EMAIL_ADDRESS>

Are there restrictions on using text (for the docs) from the Flex docs or Flex source?

I do not believe so. However when I "research" from such sources, I
generally change the text a bit even apart from the changes that the text
needs because we are in Royale-land now (strands and beads and such stuff).
Andrew
On Wed, Dec 9, 2020 at 4:00 PM estanglerbm<EMAIL_ADDRESS>wrote:

Are there restrictions on using text (for the docs) from the Flex docs or
Flex source?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/apache/royale-asjs/pull/992#issuecomment-742014136,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AC3RFXKNEERDQBDKFGTFBXTST7JNXANCNFSM4US7BRFA
.

--
Andrew Wetmore
http://cottage14.blogspot.com/
http://portfolio.cottage14.com
http://annapolisndp.ca


Columnar analyzers unable to process exclude filters properly

Bug Description:
Currently, integer columnar analyzers have issues processing exclude filters, specifically when table encoding is used. This needs to be fixed.
Manticore Search Version:
6.3.1
Operating System Version:
Any
Have you tried the latest development version?
Yes
Internal Checklist:
To be completed by the assignee. Check off tasks that have been completed or are not applicable.

[x] Implementation completed
[x] Tests developed
[x] Documentation updated
[x] Documentation reviewed
[x] Changelog updated

Fixed in https://github.com/manticoresoftware/columnar/commit/020c82ede0903f898a685cae0b5d8fcb19027771


remove  "Optional Checklist" from PR template

the pre-commit checkmark is irrelevant because of the comment made literally in the () of it
conventional commits are hot talking topic and may even introduce inconvinience to the reviewer if followed too by-the-book in the wrong way (as seen in the first ever real PR I made (uuh))

also: reorder the required checklist to this:

not all PR's touch actual ansible role code


Show button (calendar icon) on time control.

Is there a way to show button (or calendar icon image) beside textbox just like datepicker control?

i was wondering the same thing on this one.


run with python 2.6

Hi! There is the possibility to run twx.botapi in an environment with python 2.6? I use Centos 6 and I can not install python 2.7. Thank you.

Sorry, 2.6 is not supported, but we'd be happy to accept any patches that doesn't break 2.7/3.


Set a Running Status inside Repositories CRD

Set status as Running, before we run the check and get the same one as succeed.
This allows showing nicely in UI/CLI tools

we don't have to do this we just detect it from the running as we do on cli


Laravel 5

In laravel 5, the storage folder is in the root, not app/ this gives an error with:
https://github.com/peterjmit/capistrano-laravel/blob/master/lib/capistrano/laravel/defaults.rb set permissions.

Setting:
set :file_permissions_paths, [
  #'storage',
  #'storage/cache',
  #'storage/logs',
  #'storage/meta',
  #'storage/sessions',
  #'storage/views',
  'storage/app',
  'storage/framework',
  'storage/logs',
]

in config/deploy.rb seems to fix it.


[BUG] mod-log entries do not have a consistent format.

Expected behaviour
Works
Current behaviour
Doesn't work :/

They (mute, warn, note, kick, ban, unban) should be similar to the !ban format, but set the author link to https://discord.com/users/MODID where MODID is the mod's discord snowflake.

the discord.com/users/MODID is so you can search the ID and it'll work.

this is the current format of !ban for reference.


feat: #67 timeline and feed

Looks Great! Should we also take care of a minimum mobile support ? Like just adding some good paddings and breaks ?

Good point! Maybe a good time to already think about that. In general, for now I think we do best, if we just try to cover most of the app with "static" components and then start to implement data and state. We will need the app scoped components anyway, and I guess, we will change the component architecture a lot during development, also depending on state and data..


Keyboard Shortcut for adding a sub-task doesn't work in task view

It only works if I first press one of the other task manipulation keyboard shortcuts (like 'v') > 'Esc' >'q'.

Hmm, it works for me on standard todoist, but not on todoist beta.  Are you using todoist beta?

no, I'm using standard Todoist.
Can you please describe the exact step by step keyboard presses that you do?
On Sun, Mar 15, 2020 at 7:14 AM Michael Sloan<EMAIL_ADDRESS>wrote:

Hmm, it works for me on standard todoist, but not on todoist beta. Are you
using todoist beta?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mgsloan/todoist-shortcuts/issues/104#issuecomment-599169146,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIADKLMWBZLUHDZTDQCMT73RHRPZXANCNFSM4LDPYBGA
.

I press i to bring up the task view and then q to add a subtask.  o or O also works

that's exactly what I did and it didn't work (with q). But with o it works!
please update the documentation :)
On Sun, Mar 15, 2020 at 6:50 PM Michael Sloan<EMAIL_ADDRESS>wrote:

I press i to bring up the task view and then q to add a subtask. o or O
also works
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mgsloan/todoist-shortcuts/issues/104#issuecomment-599235791,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIADKLKRLSCC2IX2MABA5KLRHUBPFANCNFSM4LDPYBGA
.

I suspect it is a difference of how keyhandling is behaving in your
environment, so I am not going to update the documentation.
On Mon, Mar 16, 2020 at 2:56 AM idonimni<EMAIL_ADDRESS>wrote:

that's exactly what I did and it didn't work (with q). But with o it works!
please update the documentation :)
On Sun, Mar 15, 2020 at 6:50 PM Michael Sloan<EMAIL_ADDRESS>wrote:

I press i to bring up the task view and then q to add a subtask. o or O
also works
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
https://github.com/mgsloan/todoist-shortcuts/issues/104#issuecomment-599235791
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AIADKLKRLSCC2IX2MABA5KLRHUBPFANCNFSM4LDPYBGA
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mgsloan/todoist-shortcuts/issues/104#issuecomment-599418043,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAFQKTA5UKFIYQFOGDUUWTRHXSTJANCNFSM4LDPYBGA
.


Make scrutinizer more strict

So that @Ocramius can spend more time drinking and playing 😜

I'd just keep the defaults for now: the tool is interesting for finding low
hanging fruit issues.
On 20 Jun 2017 10:14, "Luís Cobucci"<EMAIL_ADDRESS>wrote:

@lcobucci commented on this pull request.
In .scrutinizer.yml
https://github.com/doctrine/doctrine2/pull/6511#discussion_r122907928:

   enabled: true

   excluded_dirs: ["docs", "examples", "tests", "vendor"]

php_analyzer:

   enabled: true

   filter:

       paths: ["lib/*", "tests/*"]

sensiolabs_security_checker: true

+filter:

excluded_paths:

   - docs

   - tools

+checks:

php:

   code_rating: true

The point is to also keep https://scrutinizer-ci.com/g/
doctrine/doctrine2/issues/master updated with things that we consider to
be improved (and which people could just pick up).
I mean, the defaults are fine but they're too generic... maybe we could
find a middle ground?
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/doctrine/doctrine2/pull/6511#discussion_r122907928,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJakLiVT_mXLod1gDlur3tj6YGw4npPks5sF395gaJpZM4N_Nuy
.

@Ocramius  ok, but do you agree with adding the failing conditions?

I'm fine with additional failure conditions, yes. Just overwhelmed with the
size of the diff
On 20 Jun 2017 10:20, "Luís Cobucci"<EMAIL_ADDRESS>wrote:

@Ocramius https://github.com/ocramius ok, but do you agree with adding
the failing conditions?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/doctrine/doctrine2/pull/6511#issuecomment-309680196,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJakNOD3wrU0cbTboujY__1jX8dxQoUks5sF4C0gaJpZM4N_Nuy
.

@Ocramius have fun 😉


[Feature request] HealthCheck tracking support

Hi,
Saving/tracking the whole history of health check information is very usefull on many enterprise system.
Moving health status and other related information as metrics to Application Insights , Promethus etc can be a awesome feature to be included on Health Checks.
There is any plan to include this? PR can be accepted?
Regards
Unai

Thanks for contacting us, @unaizorrilla.
@glennc, is this something we plan to add support for?

Hi @unaizorrilla - we planned for push based health checks to work by registering a long running service that calls into the health checks service at regular intervals. I think this will work better since you can control the interval, and it doesn't rely on traffic to the health endpoint to function correctly. Also it can be used by apps that aren't doing http at all!
We think that we don't really need to put a feature in the box for this, and I was going to write a sample.
What do you think about this? Have I understood what you're asking for? Should I make the sample and then we can discuss further?

Hi @rynowak!
We don't talk about the same topic :-) my fault!!
My feature request is not about executing IHealthCheckService periodically with IHostedService, configured liveness / readiness on K8S,availability alerts on AppInsights or something similar.
The "trackers" idea is the same i do on BeatPulse:
https://github.com/xabaril/beatpulse#tracking-pulses
With trackers you can send the HealthCheckReport information to third parties ( Application Insights, Prometheus, etc.) This information is very usefull to create dashboards and KPI with availability service metrics or dependencies response times.

The design for this request can be:

the abstraction for define health check tracker

public interface IHealthCheckTracker {     Task Track(HealthCheckReport report) }

the availability to register it on IHealthCheckBuilder or directly on the service provider.
Modify IHealthCheckService  to send HealthCheckReports on all registered trackers…

Regards
Unai

OK, it appears we understand each other but I'm still missing something.
An IHostedService implementation would check health regularly and push the results somewhere external
A 'Tracker' implementation would listen to health reports being produced and push the results somewhere external
Why is it better to have the latter for feeding data to app insights/prometheus?
If your goal is to capture detailed for correlation and offline analysis then we already feed that into logging. Is this not good enough?
If your goal is try and use health checks as a metric system, wouldn't you want that to be independent of someone visiting the health endpoint?

"If your goal is try and use health checks as a metric system?"
Yes
"wouldn't you want that to be independent of someone visiting the health endpoint?"
. Well, because at this moment the /[health] path only respond with status and the metrics can be more detailed with response times, dependencies ( sql server, redis .. ). Of course is posible create a new ResponseWriter but this probably  wouldn't be necessary for reqular health check request.

Because is more simple if you don't need to build nothing more to get this metrics available. AddApplicationInsightTracker and all is working!

Thanks again!
Unai

Thanks for contacting us. We believe that the question you've raised have been answered. If you still feel a need to continue the discussion, feel free to reopen it and add your comments.

We're implementing push-based health checks so that @unaizorrilla can port his code on top of it. This item tracks that work.


Automated Package Upgrade

:tada: This PR is included in version 13.0.123 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Typo in the word "SharePoint"

Before creating a pull request, make sure that you have read the contribution file located at
https://github.com/pnp/powerShell/blob/dev/CONTRIBUTING.md
Type

[ ] Bug Fix
[ ] New Feature
[ ] Sample
[x] Documentation

What is in this Pull Request ?
Typo with the word "SharePoint" in the Send-PnPMail command

Well noticed! Thanks for your contribution @ronaldmavarez .


[MM-20233] Adding cloud blackbox target discovery microservice.

Summary

Adding cloud blackbox target discovery microservice.

Ticket Link
https://mattermost.atlassian.net/browse/MM-30233

some nits and comments
thanks for this!

Thanks for the review @cpanato. All fixed :)


OG-USA developer meeting agenda 7/21/20

Agenda for OG-USA developer meeting: 7/21/20
10-11am ET
Zoom Meeting ID:<PHONE_NUMBER>
Zoom Meeting Password: ogusa
Zoom Meeting URL: https://riceuniversity.zoom.us/j/4073958475
This meeting is open to the public.
Agenda

Go over TODO's from 7/14/20 developer meeting in Issue #581
Update on dask/memory PR
Update on dynamic firms PR
Discussion of multiple industries theory and how to proceed on this front

cc: @rickecon

Short and sweet meeting today.  Rick and Jason have been busy on other projects, so there were no updates on PR #457 (dynamic firms) or PR #566 (dask/memory issues).  Jason had done some documentation work (PR #600) and shared what the OG-USA Juptyer-Book will look like.
cc @rickecon


added cookies configuration in the client and connection

We need the client to hold the server cookies information and send it back in the next rounds of querying next_page for deployment environments like K8S so that the query can hit the same pod.

If you deploy databend using helm-chart, you can add this line for service https://github.com/datafuselabs/helm-charts/commit/c2f38f5f050e5ed44bb3d11adb2153051fa63a57#diff-fc722f05e387eeac16dc6a7ee17d7266bb294d902e7e556443903ae2550af6a3R22, so it will hit in the same pod and no need to persist cookies.

@hantmac Adding this selector annotation will result in only one pod serving all traffics, including all handlers like HTTP and MySQL ones, which is not desirable for traffic loading. I think it's a more reasonable way to solve the issue by using the sticky session strategy in the Nginx ingress controller.


User Interface 2.3

Joining a few discussions: #798, #847, #844, #848, #876.
If you are working on interface updates, please:

create a separate branch in your own fork,
add a description and a screenshot to this discussion.

The idea in Cologne was to agree on the main interface changes by the end of October. I'd like to create a static HTML file containing all UI components that gives us an overview of the new look and should also give me a kickstart to write the Symphony style guide.
So let the discussion continue …

Well at the moment we've got a start of the new UI in the current integration branch, so that should be used a baseline.
You are correct though, we need to agree fairly soon so that we can the ball rolling into a Beta!

In my eyes, we have to agree on these main areas:

navigation (dark or light colour scheme)
system messages
tables
buttons
duplicators

I think we all agree that we should move away from the brownish styles (see Nils' comments in the other thread) but we have to make sure that the interface keeps a warm feeling.
Most of these things have already been touched in the referenced topics so now we have to put these things together. Some ideas work pretty well together others are conflicting – so let's just work that out in a whole.

Well at the moment we've got a start of the new UI in the current integration branch, so that should be used a baseline.

Yes, of course. The current styles reflect the status quo from June – a lot has happened since then :)

Guys (@nickdunn, @eKoeS, @phoque, @brendo), what about a UI chat early next week? Monday or Tuesday?

(Oh, it's not @phoque, it's @nils-werner here on Github – just to make sure you'll get notified.)

I'm in for a chat next week. My only doubt: how are we supposed to discuss things like colors and font sizes without starting a religion war? (It's a real question, don't want to provoke!)

My only doubt: how are we supposed to discuss things like colors and font sizes without starting a religion war?

Assign decision rights to one single person beforehand (and try to ignore the suggestions already made).

I should have a bit of spare time next week, so if it's okay for you, I'm trying to bring the different ideas together in a unified concept. As I mentioned before I thought of a single file containing all UI components in a flow. In order to compile that file I'd like to know where each of us thinks the current mockups work and where they don't – I thought a chat could simplify that discussion. I definitely don't want to discuss colours and font-sizes abstractly but we should make our different points of view clear.

We could just vote, any split vote gets decided by the single person. I think that single person should be @allen or @czheng as they have the most distance from the project (but are the closest at the same time ;)).
Meetings will need to be fairly structured otherwise they might drag, so probably best that everyone has screenshots in preparation for it so we can compare easily without people mucking around changing branches and the like.
Looks like we've got 5 things to decide on (at this stage anyway), as @nilshoerrmann has said previously.
I'm fine for either Monday or Tuesday, is that enough time for mockups to be generated?

I probably won't be able to make anything next week (super busy) but will try.

Assign decision rights to one single person beforehand

Product owner: Allen and/or Craig?

[Brendan] We could just vote, any split vote gets decided by the single person. I think that single person should be @allen or @czheng as they have the most distance from the project (but are the closest at the same time ;)).

[Nick] Product owner: Allen and/or Craig?

Looks like we are on the right track :) I agree!

Okay, what about the following:
Next week I'm going to create a HTML file with all UI components as mentioned above. I will then go through the different topics on the tracker and through the different forks and create 2-3 different styles that I make available until the end of next week.
We could then meet on Monday 31th to discuss based on these styles and vote for the different options.
Stand-offs will be decided by @allen and @czheng.

Freaky, me and Nick posted within 30 seconds of each other, whilst being 16000km apart...

@nilshoerrmann: fine for me :)

Game on. Let's do this.

Just a short note on the files I'm preparing: I've been sick for a few days and had to slow down this week so I'm a bit late. Give me the weekend to provide you with the promissed stuff. Thanks!

Glad you're back on your feet again :) Look forward to it!

Okay, guys, I'm currently working on this but I need a bit more time. I'm going to push everything to github.com/nilshoerrmann/symphony-styles as soon as I'm ready.
Would it be okay to postpone the related chat for a few days?

Definitely

Good with me also.

I started pushing a few things to https://github.com/nilshoerrmann/symphony-styles. There are experimental styles for a lighter duplicator in a separate branch:

I still need to work on the navigation. It's not as easy as I thought – the different mockups that have been posted here on Github all have different problems (proportions, sizes). I hopefully have a creative moment tomorrow so bring all these piece together. My plan is to create a separate branch for the light and the dark style.

My plan is to create a separate branch for the light and the dark style.

Pick one and run with it. Your efforts are better spent on one rather then trying to work equally on two.

Ha, yes of course, that would be "the easiest way", if I had a working idea for the header and navigation. I don't have it yet.
The header represents the Symphony brand, it should be bold, unique and not arbitrary: it should have personality. How does Symphony's visual uniqueness look like? While the content area should be quiet, the header should make you think: "This is Symphony."? What makes you think this is Symphony?
We are currently in a twilight zone: a mishmash of Symphony 2 and 3 design elements. I think the content area is on a good way, things fit together step by step – but the header is a problem.
One thing I noticed in Nick's mockups (and we already talked about that in Cologne) is the reduction of the font sizes in the navigation while I always think the fonts should be bigger. I don't think the actual font sizes are the problem but I think this situation points out that something more general is wrong with the inner proportions of the navigation and the header.
Questions
We've come a long way since we first started talking about the realign which has become a redesign since we are now officially back-porting from the Symphony 3 codebase. Maybe we need a fresh start for the header:

Should it look like Symphony 2?
Should it look like Symphony 3?
Should it be something new?
What makes you think this is Symphony?

Please post your options and ideas.
Input is highly welcome!

To answer my own question: I think we should design without restrictions – the constant comparison with the Symphony 2 and 3 styles is a problem that blocks a fresh look on the design. So for me the important questions really are:

What are the fundamental ideas of Symphony's backend design?
What makes you think this is Symphony?

Let's not stray far from the original idea of a UI refresh, we're tweaking, not redesigning, right?

Still I'd like to know your answer to what makes you think this is Symphony. :)

Should it look like Symphony 2?
Should it look like Symphony 3?

It shouldn't look like anything. It should solve the problems and shortcomings of the current Symphony 2 branch (2.2.4). Do we have a list of these anywhere? What was the main driver for the realign? Just a refresh?
I don't mind the current integration branch style, however I am weary of it becoming too glossy/glassy and looks a bit like polished chrome.

What makes you think this is Symphony?

The fact that I don't notice the UI until I jump into another CMS and feel utterly confused by the mishmash of styles, visual elements, icons and weird buttons. Symphony UI should let the content shine and therefore be minimal. I don't really pay much attention to it in my normal day to day, but it is nice to take a closer look at it and be delighted by the minor details.
I'm not saying that I don't think the realign/redesign is important, it will definitely be nice for first time users and may score brownie points with designers who are sick of other systems, but I don't think we need to try to overly impress with amazing animations and what not (not that we were going down that road anyway ;))
So with the above, wrt to your comment about the font styles, I think they should be at a size that doesn't distract from the content. The first thing I should notice on the page is the content, not the header/navigation, so the font sizes should represent that.
That's what I think anyway :)

While the content area should be quiet, the header should make you think: "This is Symphony."? What makes you think this is Symphony?

I don't think so. As a developer, you already know that you're using symphony. As a client, you shouldn't have to bother about which system your site uses. The client shouldn't think "this is Symphony", the client should think "this is my website ('s administration area)".

Maybe we need a fresh start for the header

I don't think there's something wrong with the current header, so I don't really understand why it has to be changed. If it's only for a slightly fresh look, I think the work is already pretty well done in the Symphony 3 UI, so why throw that away and start from scratch?
I like Symphony 3's UI, and many others I talked to in Cologne like it as well. Is there something fundamentally wrong with that UI that needs to be changed or fixed?

Thanks for your replies but let me clarify one thing: When I'm saying "we need a fresh start", I'm not saying "it has to be different". We just have been discussing too long over the last months under changing surrounding conditions.

I like Symphony 3's UI, and many others I talked to in Cologne like it as well. Is there something fundamentally wrong with that UI that needs to be changed or fixed?

I like the Symphony 3 UI and it has been our starting point right from the beginning. But for me the dark dropdowns don't work. But it's okay if we don't agree here.

So let's focus on how to change the dropdowns while keeping them in line with the rest of Symphony 3's existing UI.

Right, I've just pushed a few things to my styles repository, see the navigation branch. This is what I've come up with today:

But for me the dark dropdowns don't work. But it's okay if we don't agree here.

For perspective the 2.2.x branch has the light dropdown and I think it works in most cases. Sometimes you do 'lose' the navigation when you have a particularly complex site so I'm curious if a darken menu would help that. It also reinforces the separation between 'this is Symphony', 'this is your content'.
I don't think there are any fields that incorporate dropdown menus the same way though, so my worry here might be unjust.

When I'm saying "we need a fresh start", I'm not saying "it has to be different". We just have been discussing too long over the last months under changing surrounding conditions.

I'd like to have that UI meeting within the next week or two if possible, so these open air issues can be resolved with discussion/or by @allen/@czheng. We need to agree on things soon so we can get a Beta packaged up :)

I guess the dark dropdowns might actually work better because the hard contrast between the dropdown and the background will make it easier to navigate. What about combining the following two concepts into one
https://github.com/symphonycms/symphony-2/issues/798#issuecomment-2459234
Dark header (dark navigation bar AND dark dropdowns), light content area.

Yeah, it's an idea that has been mentioned before. Please fork my styles repo and add the needed styles. Thanks.
PS: I've uploaded the current status of the styles repo so you can look at the current state directly: http://projekte.nilshoerrmann.de/symphony-styles/symphony.htm

As a developer, you already know that you're using Symphony.

I think that the idea behind @nilshoerrmann's questions was to formulate a "design/branding manifesto" for Symphony, so that everything in the interface looks coherent and it doesn't feel like a mishmash of styles (as @brendo said). So, yes, I know I'm using Symphony, but I think it's also important to design the backend so that is says "yes, I'm Symphony" as well (couldn't find better words to explain the concept, sorry!).

I really like Symphony 3's UI, and many others I talked to in Cologne like it as well. Is there something fundamentally wrong with that UI that needs to be changed or fixed?

My answer is: no. I'd like to see Symphony 3's UI backported as much as possible. Which means: navigation gradients, colors, etc. I think that's the most "fair" solution.

 It should solve the problems and shortcomings of the current Symphony 2 branch (2.2.4). Do we have a list of these anywhere? What was the main driver for the realign? Just a refresh?

I think that @nilshoerrmann is more qualified than everybody else to answer to these questions. However, from my perspective, it's a realign and the reason is twofold:

Fix some "colors issues" in the current 2.2.x branch.
Reflect the organization's changes of the last years. After all, Symphony has changed a lot in the past few years (e.g. it's a fully open-sourced project and most of the people who worked on Symphony 1.x/2.0.x left the project), so I think it's important to reflect these changes in the visual styles too.

Concerning the first point: Symphony 2.3 should, in my opinion, get rid of the brown color and use a more greyish dye for the duplicator, the navigation and the login/error pages.
Concerning the second point: it's okay to work on things like buttons' rounded corners and gradients, as long as we maintain the overall structure/layout. That's why I called it "realign".
Hope this makes sense...

Ditto on @nickdunn's sentiments. I don't want the (also really good) constructive criticisms to overshadow the fact that the design is looking really great.

Thanks for your feedback, guys.
I just updated my repository with a few changes (including a lighter hover for navigation items). This is my final mockup for today which can be used as a basis for our UI chat: http://projekte.nilshoerrmann.de/symphony-styles/symphony.htm
Happy forking and happy discussing :)

Mockup looks great. I am concerned about the dropdowns though. There's no
contrast with the page itself so it feels difficult for my eye to locate
and focus on them, especially the first one, which overlays the
title/breadcrumb and first column of items.
cz
On Tue, Nov 1, 2011 at 12:36 PM, Nils Hörrmann <
<EMAIL_ADDRESS>
Thanks for your feedback, guys.
I just updated my repository with a few changes
(including a lighter hover for navigation items). This is my final mockup
for today which can be used as a basis for our UI chat:
http://projekte.nilshoerrmann.de/symphony-styles/symphony.htm
Happy forking and
happy discussing :)
--
Reply to this email directly or view it on GitHub:
https://github.com/symphonycms/symphony-2/issues/849#issuecomment-2592559

I think this as it is looks bloody brilliant http://projekte.nilshoerrmann.de/symphony-styles/symphony.htm

Like it, except of a few minor details (button texts and gradients, not enough contrast between dropdowns and background).

My fork: http://www.lineheight.net/symphony/UX-UI/symphony-styles/symphony.htm

Some changes to the integration navigation styles.
Some changes to Nils' duplicator styles
Added styles for text inputs and textareas
Added styles for field errors (see #876)

I Agree that the contrast of the drop-down menus should be somewhere in between where it is now and the dark implementation earlier.
@nilshoerrmann, Awesome tweaks and improvements!
An idea I have been thinking about is incorporating the breadcrumb into the title page itself. In other words:
Styles for Symphony 2.3 > Section > Entry

Styles for Symphony 2.3 would still take you to the front end of the website.  You could then take the create and edit buttons and move them into the top of the black bar opposite of the title/breadcrumb.  This would help reduce the vertical space used by almost an inch.

Can seemed easier to do a quick mockup in Fireworks.
![Breadcrumbs and button integration into top bar](http://whoisaccessible.com/Styles – Symphony 2.3.png)

I see where you're going, Lewis. We discussed this at length at the Symposium (we did have a long discussion somewhere online, was it Github?) and had many different iterations of moving the breadcrumb/title around: merging the two, moving the navigation above it, moving it to the footer. It was quite a contentious subject, and we eventually decided to leave it as it is, since we could always think of use cases that mwant changing it would be problematic.

@nickdunn, Dammit I'm always late to the discussions! Sorry for rehashing this concept, I had no idea. Something for the future perhaps, or maybe even an extension.

Nice work on the mockups :)
Opinions:

I feel the Alert is completely lost in the header, these are important and needs a little more emphasis.
@eKoeS, the orange is interesting, I wonder if it's too close to the 'notice' alert colour? We need to keep 'error' styling consistent between forms and Alerts. I do like how the background is separated from the message text, that's a nice touch. I also think it looks nicer without the icon :)
I prefer the smaller type and subtle styling for the navigation in @nilshoerrmann's design
The 'chrome' effect on the form elements is a touch too glossy/chromy

I really like showing all the elements on a single page like this too, it's a really quick way to see how the visual style will be across the whole backend. Nice work!

I feel the Alert is completely lost in the header, these are important and needs a little more emphasis.

I don't have as much of a strong feeling on this. I like the background colour as-is but perhaps the text colour could pop a little more to compensate?

I also think it looks nicer without the icon

Ditto. I think the colour and structure is enough of a visual queue.

I prefer the smaller type and subtle styling for the navigation in @nilshoerrmann's design

Aesthetically, I like Nils' better but Simone has improved the overall contrast. I think it's very close to perfect. Perhaps meet the two in the middle somewhere?

The 'chrome' effect on the form elements is a touch too glossy/chromy

Agreed. I think it could still work. Perhaps with the candy dialled down a bit.

Good morning everyone. Regarding the alerts:
I used a dark, low contrast version for general notices by purpose because for me the current grey in 2.2 has always be too "loud". If you comment in the success and error messages hidden in the markup, you'll see that they look different.
I'll talk to Simone how to merge the content styles.

If you comment in the success and error messages hidden in the markup, you'll see that they look different.

PS: I just added all three system messages styles to http://projekte.nilshoerrmann.de/symphony-styles/symphony.htm.

What about the different gradients for the navigation shown in @eKoeS and my mockup: Simone uses a plain gradient while I'm somehow mimicking the Symphony 2.2 glow. I wasn't sure about my version in the beginning but the longer I've been looking at it the more I'm thinking it could give the backend a more unique style. Opinions?

I like the gradient in your navigation, I think it's a good separation between header/content.

I like the idea of unifying the form styling (similar to Simone's Better Forms extension) but my personal feeling is that while the buttons should have slightly rounded corners I'd like the inputs and textareas to be squared. Thoughts?

Would be interesting to see, perhaps even a slight 1-2px radius would help?

What about the error colours? There was a separate discussion about that. I'd still prefer the bold, red styles because I know they work really well for our clients.

I think we really need to keep the red. At the moment the expectation is red for errors, yellow for notices so I'm weary that removing red and making the yellow an 'error' is going to be a confusing experience (especially for users who might be using both Symphony 2.2.x and 2.3.x versions). I think the red needs to stay honestly. I still feel the general notice could be dialed up a few notches, it still blends into the header and isn't distinct on it's own (maybe this is just my screen?)

In my eyes the code block styles from the event editor are strange (I haven't changed anything yet). I was thinking if we could make it look like the debug mode and use Bitter as soon as the devkit is available.

Would Bitter's dark theme clash? I almost feel the less we do in regards to code formatting the better, as it's very subjective and everyone prefers something different (I'm actually surprised no one has brought up theming for the devkit!)

The idea is to have a dark header and a light content area which is why the styles of the Duplicator changed. While it still need some tweaking regarding the general contrast, I'd like to use the rounded corner box with the light shadow as a general template throughout the backend: Duplicators, frames (used for uploads and downloads), login form, exceptions.

Looks good.

My mockup of the Duplicator uses a button for removing items I was thinking about a simple wordless button for the Add item menu as well:

I like words to be honest. I don't like icons. To me that is one of Symphony's defining factors actually. I'm weird though :)

I really like both efforts.
I prefer the simplicity of Simone' nav background gradient, but prefer everything else in Nils' navigation/header. The darkest alert bar could do with the text lightening slightly to increase contrast, but the background seems good. I don't think the text/hyperlink actions need to be replaced with buttons or icons, they work fine as they are.
My only other suggestion are to increase contrast on each duplicator header ("Text Input") as they are totally lost right now (when I scan down the page it feels like one long form without any headings) and to increase the size of the actions/tools panel at the bottom of the footer, since the dropdown looks lit tight.
I really like the idea of styling form widgets with CSS (borders and backgrounds) in Simone's example, but I think it needs to be more subtle. The dark borders and unnecessary shadows add a whole load of visual clutter in my view. It reminds me a bit of when comparing Tweetbot (screenshot) which is subjectively "beautiful" but is riddled with unnecessary keylines, gradients and shadows and the official Twitter client (screenshot) which is simpler and feels more "native".
I'm not against styling form widgets per se, but conscious that it adds complexity but visually and for maintenance.

I like words to be honest. I don't like icons. To me that is one of Symphony's defining factors actually. I'm weird though :)

One factor why we like it or hate it may be our mother tongue: German phrases are usually longer and in the context of the buttons it's not always possible to find elegant translations. So, me personally, I really don't like the text "buttons".

One factor why we like it or hate it may be our mother tongue: German phrases are usually longer and in the context of the buttons it's not always possible to find elegant translations. So, me personally, I really don't like the text "buttons".

Ah good point! One of the original drivers with the S3 styles was to eliminate all images and have everything powered by CSS, I think that's still a worthwhile goal.

I'm not against styling form widgets per se, but conscious that it adds complexity but visually and for maintenance.

I guess it's idea that not every element on the page has to have 'something', but really they should all work in symphony with each other to create a great experience (you see what I did there :D)
I think both efforts are really good and it's definitely progression :)

One of the original drivers with the S3 styles was to eliminate all images and have everything powered by CSS, I think that's still a worthwhile goal.

How is that related to the buttons? They don't use images just plain text.

It wasn't, it just made me think of it :) If you put one foot down that road now, it's hard to defend any position in the future. +, -, x and ! invariably lead to more complex icons that are difficult to represent with characters. Just something to keep in mind really.

Two changes:

More subtle separation between breadcrumbs/actions bar and content with less of a border/shadow.
Idea: breadcrumbs

Modifications: http://casadelewis.com/ui/symphony.htm
Fork: https://github.com/lewiswharf/symphony-styles

lead to more complex icons that are difficult to represent with characters.

Universal icons are tricky too.

For example: http://nils-werner.github.com/symphony.htm

Whoa I never knew github did that! Nice trick ;)

http://nils-werner.github.com/symphony.htm
Two changes: I've made the duplicator instance headers a bit darker and strengthened the pop-out-effect when reordering them.
Also I've noticed that I didn't like the white sub-menus as opposed to the dark ones. It takes quite an effort to recognize them, especially the active (the blue item) one.

Whoa I never knew github did that! Nice trick ;)

Indeed, thanks Nils!

Yeah they've been tone down since this.
http://nick-dunn.co.uk/assets/files/s3/buttons.html

Wow, so many replies since yesterday!
Error colours

[brendo] @eKoeS, the orange is interesting, I wonder if it's too close to the 'notice' alert colour? We need to keep 'error' styling consistent between forms and Alerts. I do like how the background is separated from the message text, that's a nice touch. I also think it looks nicer without the icon :)

[Nils] I'd still prefer the bold, red styles because I know they work really well for our clients.

[brendo] I think we really need to keep the red. At the moment the expectation is red for errors, yellow for notices so I'm weary that removing red and making the yellow an 'error' is going to be a confusing experience (especially for users who might be using both Symphony 2.2.x and 2.3.x versions). I think the red needs to stay honestly. I still feel the general notice could be dialed up a few notches, it still blends into the header and isn't distinct on it's own (maybe this is just my screen?)

As a said in the other issue, I don't think that it's mandatory to have flame red for errors. I also think that changing the colors from red to yellow/orange wouldn't be much of a problem, as long as the new styles catch the user's attention and communicate that something was wrong with filling in the field. As far as I know, @designermonkey is working on a variation that uses soft red, which is still an improvement compared to the bold one we have now, in my opinion.
I really don't think that we need to stick to the traffic lights methapor. Indeed, yellow is already used for system error messages, so it seems that methapor has already been broken... If you don't like yellow or orange, can't we just use a red tone that is not a pain for the eyes?
Concerning the icon: it's horrible but wanted to have a try. :)
Navigation gradient
I deciced to fork Nils' mockup because I wasn't and am still not convinced about the navigation gradient. It looks too "bevelled" and "embossed" to me, while the backend uses "flat" styles. I'm also not really keen on the contrast for the :hover state.
I like the gradients used for the Symphony 3 demo and in Cologne most of the people agreed to backport them. Moreover, I don't think that it's that important to mimick the Symphony 2.2 styles after all. Symphony 2.3 already introduced some big changes, I don't think we should be afraid of doing the same for the backend UI (as long as we keep intact the layout, as I said some comments ago).
Duplicator
My fork features a lighter and more subtle version for the duplicator. While I think that Nils' changes are the way to go, I think that it is still too "dark" and doesn't sufficiently distinguish the selected element from the others while reordering. Would like to get some feedback on that.
Text input styling

[nils] I like the idea of unifying the form styling (similar to Simone's Better Forms extension) but my personal feeling is that while the buttons should have slightly rounded corners I'd like the inputs and textareas to be squared. Thoughts?

You mean completely suqared? Wouldn't that clash with the rest of the styles?

[nickdunn] I really like the idea of styling form widgets with CSS (borders and backgrounds) in Simone's example, but I think it needs to be more subtle. The dark borders and unnecessary shadows add a whole load of visual clutter in my view. It reminds me a bit of when comparing Tweetbot (screenshot) which is subjectively "beautiful" but is riddled with unnecessary keylines, gradients and shadows and the official Twitter client (screenshot) which is simpler and feels more "native".

Nothing to add, I think you are right. Please feel free to improve upon my styles!

As far as I know, @designermonkey is working on a variation that uses soft red, which is still an improvement compared to the bold one we have now, in my opinion.

When I get some time, I may just have to provide some colour codes for someone else to do it, me a busy chap.

This is great feedback here – I think we are really coming closer to our final draft. Thanks a lot guys!
It seems like the general direction is fine but that there is especially room for improvements regarding contrasts (notices, navigation drop downs, Duplicators). @eKoeS, what about having a chat tomorrow how to merge the different approaches for the content area?
Regarding the header
There seem to be two groups, one favouring the continuous gradient and another favouring the more distinct one. I can live with both and I think we should not discuss this for too long: it would be nice if @allen and @czheng could just decide which approach we should stick to.
The contrast and visibility of the navigation drop downs are a related issue. I've been trying a lot of different things locally and in my eyes the navigation should either be completely light (light bar + light drop down) or completely dark (dark bar + dark drop down). Personally, I prefere the light flavour because this is what Symphony always looked like and I don't see a need for change here. This, of course, is just a matter of taste. No matter which approach we take, things have to make it readable and visually clear and contrasty. So we need a decision which general approach to follow (dark or light) and – again – I think it would be a good idea to let @allen and @czheng decide on that.

How's about we have a meeting next Thursday (timezones)? Is that too far away? Does that suit?
The purpose will be to discuss any open ux-ui issues. @allen and @czheng will be the decision makers (where needed) and we'll generally touch base on timings and schedules to see when a 2.3 Beta is feasible.

Thursday sounds good and it gives us enough time to create a unified mockup.
Nevertheless it would be great if @allen and @czheng could decide on the mentioned points above because I don't think an open discussion will help us – we have been discussing for a few months now with controversial opinions or feelings. We just need a decision.

I agree Nils.

@eKoeS, what about having a chat tomorrow how to merge the different approaches for the content area?

That would be great. There's only one problem: I'm at uni from 10:00 to 20:00 every day, is it okay for you to chat later in the evening?

Ah lets say Saturday or Sunday then.

Weekend works better for me also. I'm around all weekend.

Yep, same here.

@allen: Simone and I will meet on Skype tomorrow at 13:00 Berlin/Rome time, if you're around and like to join us please do.

So do we still need a meeting to finalise a couple of things? How'd did the meeting go last Sunday (?).
I'm mindful that we can't really package a beta at this stage with half a UI, so I'm keen to push on with this and happy to help anyway I can to make this a reality (I know December will be a writeoff for most, so anything we can do to package this in November will be outstanding)

How'd did the meeting go last Sunday (?).

Sorry for not posting any summary! Allen joined us to talk about our two mockups and make a few decisions. In short:

Gradients: as in Nils' mockup
Dropdowns contrast: as in Simone's mockup, with a few refinements
Errors: as in 2.2.x
Font sizes: as in Simone's mockup
Textinput styles: Symphony 2.4
Buttons: as in Nils' mockup

To discuss:

Duplicator styles

Perhaps I forgot something, but that's the big picture. @allen, @nilshoerrman, anything to add?

I'm mindful that we can't really package a beta at this stage with half a UI, so I'm keen to push on with this and happy to help anyway I can to make this a reality (I know December will be a writeoff for most, so anything we can do to package this in November will be outstanding)

Yep, I agree. We wanted to discuss these UI-related things soon and quickly just for this reason. I think Nils and I should be able to send a pull request by the end of next week.

I've aleeady unified the navigation styles locally so we mostely have to work on the duplicator styles. Simone and I will prepare everything for review.

 Thank you.
Cheers for the update and I look forward to the pull request!

@eKoeS: I pushed the updated header styles to my Symphony fork at nilshoerrmann/symphony-2. So the header should be done now.
I'd like to tackle margins and paddings next – if you like to work on the Duplicator styles, please do.

Is there a canonical demo page incorporating the feedback from the meeting, like a current progress demo?

http://projekte.nilshoerrmann.de/symphony-styles/symphony.htm is up-to-date.

Looks pretty good so far, I like it.

The buttons just don't fit the rest of the styling. They look too soft in comparison to everything else.

if you like to work on the Duplicator styles, please do

Doing it right now.

Looking good, only comment at this stage would be a more obvious hover/focus state for the 'Edit Section' button, aka. .button rule.

Can I add my own quiet 2 cents regarding the buttons? I concur with @designermonkey – they're quite blurry and hard to read. The face and size of the font used on the buttons in integration currently is also inconsistent with the rest of the UI, which seems really out of place.
OK, back to hibernating.

Looking good, only comment at this stage would be a more obvious hover/focus state for the 'Edit Section' button, aka. .button rule.

We haven't touched the button styles in a while but I think you're right that distinct hover states could improve the buttons a lot. Not sure yet how that might look like though.
Suggestions?

Killing the text-shadow on the buttons makes them much crisper.
The face and style in Nil's mockup is consistent with everything else.
Nils, does your mockup include the latest navigation changes? It looks pretty different to what I thought we had moved towards.
http://projekte.nilshoerrmann.de/symphony-styles/symphony.htm

Did anybody notice my message about the Duplicator "while reordering" style I made?
http://nils-werner.github.com/symphony.htm

I did notice it. We didn't get to talking about the duplicator as it wasn't chalked up for discussion. That said, in my opinion it's the best implementation yet so far. It's very clear to the user which item they're reordering.

Neat! I think it's actually a good effect, the shadow might be a bit overdone though?

Yeah I think the shadow is pretty overpowering, but a nice effect. I still feel the duplicator needs better header styling. I think it was addressed, but doesn't seem to be in Nil's version.

Yeah, the shadow was the first thing I was playing around with. In combination with the nudging it looks kinda heavy. Glad you noticed and liked it :-)

Continuing to my thoughts on the current menu hover state:
I see the backend as an attempt to visually recreate a realistic, haptic surface. So I see things as actually beveled, hovering, sitting on top or besides one another. This implies that every fade, dropshadow, textshadow, border etc. would actually make sense from a perspective point of view. I guess we're all seeing that but I just wanted to make sure you know where I am coming from here.
Attached are a few rough sketches that try to picturize what I mean.
Current design mockup
The dropdown appears to be a flat sheet of paper, coming from below the menu bar. The shadow doesn't make much sense as there is virtually no distance between the background and the dropdown.
Secondly, the background-color of the active menu item and the dropdown are severely disconnected: Making the active element darker than the default state but invoking a bright-white dropdown visually disconnects those two for me.
But then, the menubar hover-color is not even the same shade of grey than the dropdown hover-color. Another disconnect.
What I had in mind
Giving the active item and the dropdown the same background color makes the dropdown appear to be one single component, hovering above the main menu bar.
By having the same background-color, the two elements feel connected again and the dropshadow makes sense as there is a noticeable distance between the dropdown and the background.

What he said, I agree fully. It gets rid of the circular discussions about what the selected state should be (grey? blue?).

Makes sense to me. I'm biased because you included a sketch. I love sketches.
Seriously though, it's a fair argument and it's a subtle change but does make a difference.

I like @nils-werner's idea but which colour to use for selecting of a submenu item?

Nils, does your mockup include the latest navigation changes? It looks pretty different to what I thought we had moved towards.

The mockup includes all changes discussed with @allen a few weeks ago.

By the way, I have a personal wish: I know that we all don't have much time and that some of us are jumping back into the discussion after a moment of silence. Please read the full thread first before commenting – we have a few "recursive discussions" here. Thanks!

@nilshoerrmann That's a perfect cue for my next argument: The discussion about the bright vs. dark menu.
To me, the bright menu simply doesn't do it. Even with short menus it is kind of tricky to make out the menu from the content table or even the background. It is possible, but not immediately visible:

Now if the menu grows in length the issue becomes much more troublesome: In the worst case the lines of the content table lign up perfectly with the menu items, almost camouflaging them completely. Again, you can read them, but it takes quite an effort mentally and visually.

Also, I believe there is a common scenario where people are searching the right submenu item by switching between main menu items quickly. It would be pretty hard to do as you're not only scanning for a line of text but always looking for the subtle hint that assures you've found the correct box in the first place.
Now if the menu was visually disconnected from the content by a high-contrast box, those issues are solved almost immediately. You don't have to make sure your eyes stay inside the menu box, the contrast does that for you. You can always be sure you never switch reading-context by accident.

The same holds if the menu grows in size, everything stays perfectly readable and instantly recogniseable.

While a dark menu might help with regards to contrast, it's a mess visually.
I'm not against a dark menu per se and I don't think the current implementation is perfect, but we need to find a compromise between aesthetics and usability. I know that we won't find a solution by discussion this over and over again which is why I asked @allen to decide. The result is what you see in the current mockup.
I personally don't care as long as result is usable and looking good.

Yep, makes sense. Remember it's difficult for us to know what has or has not been addressed if we weren't at the meeting.
So as I see it there are three areas of concern where the current current styling feels incomplete:

Navigation: selected states and dropdown colours are still in discussion; in light of Nils W's concepts (which I think are very good points)
Buttons: suggestions that styling needs to be refined; concern that they are muddy and not as crisp/bold as other parts of the design
Duplicator: heading contrast of each item (was addressed here but not carried through to Nils H's mockup) and drag state

Concerning the duplicator styles: I've already pushed a few changes to @nilshoerrmann's symphony-2/integration repo a few days ago. I personally don't like @nils-werner's mockup because, except for the big shadows on the selected element, all the items look the same while reordering.
Note: I'm currently at the Italian UX Camp so I don't have time to elaborate and post more thoughts, will do as soon as I can!

all the items look the same while reordering.

I actually though that pulling the item out and to left by the 15/20px was a nice distinction to let you know which item was being moved around.
Something else, multiple alert styles, this is possibly related to #840 in terms of Javascript functionality though.

I'm currently at the Italian UX Camp

Sounds fun!

I like the idea of using shadows to get a "pop-up" effect, but as Nick said it was a bit too much. Moreover, I think that the background color for each element is too dark/flat and makes the duplicator look like Windows 95. Today I've found some time to work on my mockup and try to improve upon Nils W's work. Here's the result:
http://ekoes.github.com/symphony-styles/symphony.htm
The idea is to use shadows in a similar way as Nils W did, but in a less obtrusive way. I also tried to increase the contrast on each element header as Nick suggested. The main difference, however, is that when you select an item for reordering the others become half transparent, which is why in my previous post I said there isn't enough distinction between active/unactive items. Last but not least, the flat background colour has been replaced with a subtle gradient with a lighter grey.

Sorry if it was a misconception that my mockups should be the final design with all bells and whistles. I'm just using them to get an idea or concept across.  :-)
I was thinking about taking a similar route as Simone did: fading out/darkening the remaining elements when selecting/dragging one of them. Eventually I abandoned that idea because it worsens one of the problems with drag'n'drop interfaces: You need to find the element you're moving, select it and drag it around while knowing where you're dragging it to.
Fading out the remaining elements was no option as it makes it unnecessarily difficult to see if the target location is actually the correct one.
I was also thinking about using CSS transitions to make the pop-out-animation a bit smoother; I just didn't find the time to do so. Now that I've seen your draft I must say I don't like it too much: The current 2.1 interface itself feels clunky and slow already. I attribute this feeling to the huge size of the draggeable elements, the not immediately visible positioning and target area and the necessity to scroll around when you're dragging across more than just one position.
Adding both an uninterruptible start- and stop-animation to that clunky process makes it feel even slower and more uncomfortable for the user and raises the fear of unintended clicks or premature releases.

Sorry if it was a misconception that my mockups should be the final design with all bells and whistles. I'm just using them to get an idea or concept across.

No worries, I know and I appreciate when people comes with new ideas! I don't think anybody here thinks his work should be the final design. ;)

[...] big shadows are a thing of the past. :-)

Actually I was already referring to the updated mockup. I think they are stil too big :/

I was thinking about taking a similar route as Simone did: fading out/darkening the remaining elements when selecting/dragging one of them. Eventually I abandoned that idea because it worsens one of the problems with drag'n'drop interfaces: You need to find the element you're moving, select it and drag it around while knowing where you're dragging it to.

I can see your point, but the current duplicator darkens unactive elements and nobody ever complained. You can still see them, they just look a bit different. As I said, I like the idea of shadows, but in my opinion they are too "bold" and big. My idea is: using less obtrusive shadows, coupling them with half transparency ("half" doesn't necessarily mean 0.5 though) as a different type of visual clue.

The current 2.1 interface itself feels clunky and slow already. I attribute this feeling to the huge size of the draggeable elements, the not immediately visible positioning and target area and the necessity to scroll around when you're dragging across more than just one position.

Symphony 2.3 should land with a small update that makes all the existing elements in the duplicator collapsed by default. It doesn't solve the problem, but it's a start.

Adding both an uninterruptible start- and stop-animation to that clunky process makes it feel even slower and more uncomfortable for the user and raises the fear of unintended clicks or premature releases.

I'm not sure I follow. I must premise that I added transitions just for fun. They are not useful, but I find them elegant and fast enough not to break anything in my opinion. But as I said, I didn't get the whole "unintended clicks or premature releases" thing, can you explain?

I won't have any spare time for Symphony over the next week due to a project deadline so I don't have the time at the moment to make additional mockups. But there is one important thing I'd like to throw into the discussion: that's consistency.
Navigation
We have a strong visual structuring in the current mockups that expands horizontally:

There is a dark title bar,
followed by a gray action (= navigation) bar,
completed by a white content area.

So if we are talking about the navigation drop downs, we have to recognize that they are vertical "disrupters". This is a good thing because they are pointing to an action that will change the layout of the backend. But when styling the drop downs we have to make sure they are anchored at the right place. Just locking at contrasts, using dark drop downs makes the second menu level belong to the title bar and not the navigation bar itself. That's a big problem in my eyes and it's the main point why I think the dark drop down are a mess in the current context. I mentioned it earlier in this or the other thread that I think we should either go with a light navigation or a dark navigation – and that applies to the main and the sub menu.
Personally, I prefer the light version because it feels more consistent with the 2.0 and 2.1 releases of Symphony. I understand the need of contrast but that's a thing that should be solvable in both, a dark or a light design. Has anyone ever complained about the contrast of the current 2.1 drop downs? If no, why are they working compared to the updated ones? (That's serious question!)
Ordering
Ordering in Symphony 2 has always been inconsequent:

In lists or tables, Symphony 2.1 highlights the selected row by darkening its colour.
In Duplicators, Symphony 2.1 darkens the unselected rows.

This is something we should solve in Symphony 2.3 – we should find a consistent way to highlight ordering processes.
In this context we have to acknowledge that Symphony 2 opted for special ordering concept: there is no drag helper as in most operating systems. The selected item just jumps/reorders while moving the mouse – we are not seeing a semi-transparent copy of the selected element that we can drag and drop to its new position. @nils-werner's idea to order the Duplicator seems to be something in between both concepts: it doesn't use a copy but it moves the selected element out of its container.
If we consider the ordering style of tables as the canonical one, the Duplicator should just darken the active item. If this is done with enough contrast, I just works for me (it always has in Symphony).
If we consider the ordering style of tables as insufficient, I think we should have a look at the drag and drop concept for ordering as we know it from the OS world. Popping out elements doesn't feel very Symphony-like as it doesn't solve to main problem: highlighting the active object in a simple way.
If the majority doesn't agree and popping out element is the way to go, we have to make sure to use this concept consistently: ordering should work the same across the interface.

Okay everybody, we've got a problem. Actually, more than one.

We are talking about two or three different things in the same big issue. As a result, it's really difficult to follow threads. Solution: I'll create separate issues, highly specific ones and will try to moderate them so that everybody stays on track.
Ideas work better in form of mockups. It's okay to discuss concepts and post screenshots, but Nils has got a repo just for this reason, so please fork it and post a link to your work.
We keep discussing things that were decided time ago. I understand that 2.3 UI is a delicate matter, but we've got a deadline. Two weeks to get everything sorted out. Let's keep that in mind.

Please from now on use this place only for coordination purposes (e.g. WG chats) and wait for the new issues to be created (doing that right now). I'll try to author a structured summary at the top of each issue as the discussions evolve so to improve readability and facilitate communication. Thanks for your patience!

We keep discussing things that were decided time ago. I understand that 2.3 UI is a delicate matter, but we've got a deadline. Nine days to get everything sorted out. Let's keep that in mind.

It's nine days, but it's not nine days to a final release, as I've mentioned inside the other issues, we are all close to this now and I think some real user feedback (not that we aren't users, but you know what I mean) from a Beta release will be balancing and put some perspective on it. I love how we are all perfectionists, but it's a curse at the same time ;)

I have a question:
We are a small group of people working on the interface and we have seen different approaches for this or that area of the backend here on Github. In my eyes – when we agreed which concepts to use for which area – somebody has to merge and edit the styles so that the end result will be structurally and visually consistent.
Shall I continue to do this?
If yes, how do we decide about the final concepts?
If no, who is doing this?
When should the style merging be done?

I just realized that forcing issues #905, #906, #907 to be closed in time for 2.3 Beta 1 is a mistake. We should keep them open as long as it's necessary so to give people more time to discuss and contribute. Let's just bundle the current integration styles in the first Beta.

Hm, I'm not sure, a few things should be polished first.
In general, I think we need to find a rhythm for our discussions: there need to be decision points to agree on and to define the UI goals for the next release and there need to be discussion breaks where things are implemented. These implementation - beside minor fixes - should go into the next release. New ideas can be considered for the release after that.
I think we need one or two editors who organise this process and who are taking care of pulling style changes into the main repo. Someone like Brendan who is keeping an eye on what is going into the core. This person should not be respnsible for the design but should have and eye on the consistency and structure of the styles. He should guide the process.
Maybe it would be good to have one editor for the CSS and another for the scripts.

Hi, I just pop in on this thread, I've read it (although not thoroughly), but I have two questions:

eKoes said: "Textinput styles: Symphony 2.4". Is this true? If so, why? Can't the text inputs and text areas be styled to match the look and feel of the other elements?
Secondly: I don't see any mention of select-boxes with or without multiple="multiple" (multi-selectbox) here. I really think the "Hold Ctrl while you're clicking"-approach is ok for developers, but for our final end-users, our clients, this feels a bit flaky. Can't we use an approach like the Better Forms-extension or multiselect-to-checkboxes -extension does?

Sorry for dropping in late, have been working with some mighty deadlines lately. :-(

Yes, we needed to concentrate on the most important things first (otherwise 2.3 will never be ready). And the styling of form elements is a huge and delicate task.
We are considering concepts similar to Chosen.

All linked issues in the original discussion have been closed, hence this issue is closed. We have new TODO list issue, #1024 which will house a todo list of all interface bugs.


Cant override --color-background token

Hey Folks,
i tried to override the --color-background in a tokens.css of my next 13 / app router project. But it seems like it is resetting all the time.
The light mode should have a "beige" background, but the rendered html file still contains this:
<style>
            :root, .light, .light-theme {
                --color-page-background: white;
            }

            .dark, .dark-theme {
                --color-page-background: var(--sage-1);
            }

            body {
                background-color: var(--color-page-background);
            }
        </style>

layout.tsx
import<EMAIL_ADDRESS>import type { Metadata } from 'next'
import { Theme, ThemePanel } from '@radix-ui/themes'
import Footer from '@/components/Footer'
import './globals.scss'
import './tokens.css'

tokens.css
@font-face {
  font-family: Montserrat;
  src: local('/fonts/Montserrat-Italic-VariableFont_wght.ttf');
}
.radix-themes {
  --default-font-family: 'Montserrat';
  --heading-font-family: 'Montserrat';
  --quote-font-family: 'Montserrat';
  --font-weight-light: 300;
  --font-weight-regular: 400;
  --font-weight-medium: 500;
  --font-weight-bold: 700;
}

:where(.radix-themes) {
  --color-background: beige;
  --color-overlay: var(--black-a6);
  --color-panel-solid: beige;
  --color-panel-translucent: rgba(255, 255, 255, 0.8);
  --color-surface: rgba(255, 255, 255, 0.9);
}
:is(.dark, .dark-theme),
:is(.dark, .dark-theme) :where(.radix-themes:not(.light, .light-theme)) {
  --color-background: var(--gray-1);
  --color-overlay: var(--black-a8);
  --color-panel-solid: var(--gray-2);
  --color-panel-translucent: var(--gray-2-translucent);
  --color-surface: rgba(0, 0, 0, 0.25);
}

or did i miss something here?

I think you should move your color tokens inside
.radix-themes{}

I fixed this issue using Layers https://developer.mozilla.org/en-US/docs/Web/CSS/@layer
@layer tw_base, mantine, radix_ui, tw_components, tw_utilities;
@import 'tailwindcss/base' layer(tw_base);
@import 'tailwindcss/components' layer(tw_components);
@import 'tailwindcss/utilities' layer(tw_utilities);
@import<EMAIL_ADDRESS>@import<EMAIL_ADDRESS>layer(radix_ui);

would maybe try the solution above if i would not solve it with an !important
but it meant to work different from radix-ui/themes - am i right?

I encountered a similar issue with overriding the next/font, but it was resolved by modifying the file structure as follows, based on the previous answer(@ajdiyassin):
layout.tsx
import "./theme-config.css";
import './globals.css';

globals.css
@import<EMAIL_ADDRESS>@tailwind base;
@tailwind components;
@tailwind utilities;

I encountered a similar issue with overriding the next/font, but it was resolved by modifying the file structure as follows, based on the previous answer(@ajdiyassin):
layout.tsx
import "./theme-config.css";
import './globals.css';

globals.css
@import<EMAIL_ADDRESS>@tailwind base;
@tailwind components;
@tailwind utilities;

We added suggested workarounds for these common issues:

Next.js import order
Tailwind overrides

This isn't something Radix Themes can control, unfortunately.


Android was not automatically link

I use react-native link for our library but it just automatically linked to my ios project, on Android version, I had to manually link.
But it throw an error:  "io.callstack.react.fbads.FBAdsPackage" does not exist.

Does it link other projects to your Android? Please double check as it's likely an error on your side. Happy to provide you some tips.
I assume that after manual linking everything went well, right?

I think the problem was about your newest update, my colleague had the same issue, too. Linking manually made everything ok but that's a waste of time.

@grabbou I think manually linked like your example is not working


request body empty

If Request doen't have body but response is going to be msgpack encoded. in that case body.text empty check is req. and return if body is empty

Hi @govind-maheshwari2 Thank you for taking time to look into this project.
I'm not sure I understand the problematic here. When plugin is enabled, what happens if body is empty ? Assuming the endpoint you are sending request to doesn't look into body and returns msgpack response, plugin will automatically decode it.
What is the purpose having return early if body is empty ?

Hi @dinkopehar
This issue is if we send request with empty body with plugin enabled then it will give error as it is trying to encode empty string.
As code fails at encoding only it will throw error then request will not be sent by insomnia.
You can repro this by sending no body to any request.

Oh, I didn't checked all exceptions.
When I tested, I assumed the body of request and response would not be empty. I didn't checked for cases you mention. There is also similar issue open.
I'll approve these changes, thank you :rocket:

Hi @dinkopehar
Any plans regarding deploying the plugin with this change?

Hi @govind-maheshwari2
I just republished the package and tested installing it. You can also delete the previous version of plugin or update existing one to 0.0.4


Add new commands to Discord

This adds some new commands to discord, and additionally fixes an existing command.
I have only implemented these commands currently on Windows, as that is the OS that I use.
This is my first contribution to this repository, so do tell me if I'm doing anything wrong.

I just fixed the merge issues related to some of the bigger commits recently


rPackages.tesseract: fix build

Description of changes
Fix build of rPackages.tesseract by explicitly adding leptonica to the
build configuration. Resolves #271529.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

This fix works for me. Thanks @jbedo


python3Packages.coinmetrics-api-client: 2<IP_ADDRESS> -> 2<IP_ADDRESS>

Description of changes
Commits.
Also:

nix-update-script was enabled
Type checking is now part of the tests

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[x] x86_64-darwin
[ ] aarch64-darwin

[x] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/2165

Please don't request my review for cryptocurrency packages.

@ofborg build python310Packages.coinmetrics-api-client


"TabError: inconsistent use of tabs and spaces" on Python 3

Hello,
I'm trying out your code on Python 3 and have found a problem in that python 3 disallows mixing tabs and spaces for indentation. As a result the library doesn't work /w 3. For some context around this see:
http://stackoverflow.com/questions/19295519/indentation-error-with-python-3-3-when-python2-7-works-well
You can probably change all the files in bulk using sed, like in this example:
http://stackoverflow.com/questions/11094383/how-can-i-convert-tabs-to-spaces-in-every-file-of-a-directory

@gregretkowski I put PLE through autopep8. Can you let me know if it works now?

Looks good. I grepped through the source and all the tabs are removed. Thanks!


Execution Flow Branching

Is your feature request related to a problem? Please describe.
When I explore new ways how to use a nuget package I prepare all required dependencies eg. "#r "nuget:..." and objects to work with.
After that I start to play with it. At certain checkpoints I want to change the execution flow to see alternative ways to use it but don't want to create a new notebook.
The same is true for working with sql data and different ways to visualize them without throwing already written code away.
Describe the solution you'd like
I want to add one/more vertical slices after a "checkpoint step" to have multiple execution alternatives.
Kind of LogicApp designer but easier to use.
Describe alternatives you've considered
I could achieve the same with multiple notebooks and include files to share certain pre-steps, but this would allow only a single branch checkpoint.

Would this interaction model need a different UI so people understand the branching? Notebooks are very linear.
Another question this raises for me is whether #!import can be used in this way. Each branch could be a separate notebook with predecessors indicated by #!import. For example, common steps could be a.ipynb while branches could be a.1.ipynb, etc,. via #!import a.ipynb.

Notebooks are very linear.

I think notebooks really try to invite the user to play with data and supporting branching would also allow play with different flows.
Looking forward for other input!


Improve the routing docs for getting page params

Describe the problem
This is not really a feature request, nor a bug report but a suggestion to update the docs.
I was trying to access the query parameters from the route. The Endpoints chapter in the documentation presents rather a clunky way to do that. Besides being not very elegant, I had quite a problem with it, that such code was causing error 500 for me in some cases. I've prepared a repository demonstrating it if you'd like to see it here.
The solution was much, much simpler than the one described in the docs:
<script lang="ts">
  import {page} from '$app/stores';

  export let name = $page.params.name;
</script>

I've spent quite some time figuring it out when it could be simply put in the docs. I know that this way it's not reactive, but making it reactive is also quite simple:
<script lang="ts">
  import {page} from '$app/stores';

  export let name: string;
  $: tab = $page.params.name;
</script>

Describe the proposed solution
The docs should be updated showing the simpler solution at least as an alternative.
Alternatives considered
No response
Importance
nice to have
Additional Information
No response

Closing this as I'm not sure it's specific enough to act on. The endpoints documentation isn't showing how to access parameters, it's showing how to load data based on parameters, which isn't equivalent to accessing $page.params.whatever. Documentation on how to access parameters in a page is in https://kit.svelte.dev/docs/routing#pages


Allow multiple service Ids to be passed

Summary of PR changes
Allow multiple service ids to be passed as an option.  A handful of teams have created more than one PagerDuty technical service to support their infrastructure.  Calling this action for each technical service within the same workflow is tedious.  It is easier to include all PagerDuty sevice IDs in a single variable that is assigned to each enviroment.
Resolves #2
PR Requirements

[x] For JavaScript actions, the action has been recompiled.

See the Recompiling section of the repository's README.md for more details.
This does not apply to Composite Run Steps actions unless a package.json is present and contains a build script.

[x] For major, minor, or breaking changes, at least one of the commit messages contains the appropriate +semver: keywords.

See the Incrementing the Version section of the repository's README.md for more details.

[x] The examples in the repository's README.md have been updated with the new version.

See the Incrementing the Version section of the repository's README.md for more details on how the version will be incremented.

[x] The action code does not contain sensitive information.

Tested passing just service-ids:

Tested passing single service-id for backwards compatibility.


Open URL in the browser

Describe the feature
This feature will ask the user (using a optional parameter) if they want to open the outputted url in their default browser.

Hi. Thanks for this idea! I have a question though. How would this be used? There are multiple uses of Searchor, for like bots, small projects, etc. I don't get how this would work. I appreciate your idea again but could you describe a little more on what you specifically mean?

If people want to open the link directly in their browsers, for example - If in a bot, you provide it a query "Hello World", and it returns the url, but using this method we can open that url in the browser too!
Also this feature would be optional, so if a user wants only the url to be outputted, and not to be opened in the browser, then he can opt for that too.

If people want to open the link directly in their browsers, for example - If in a bot, you provide it a query "Hello World", and it returns the url, but using this method we can open that url in the browser too!
Also this feature would be optional, so if a user wants only the url to be outputted, and not to be opened in the browser, then he can opt for that too.

Are you saying for this to be related to the terminal?

If people want to open the link directly in their browsers, for example - If in a bot, you provide it a query "Hello World", and it returns the url, but using this method we can open that url in the browser too!
Also this feature would be optional, so if a user wants only the url to be outputted, and not to be opened in the browser, then he can opt for that too.

Are you saying for this to be related to the console only?

Yeah, but I guess this thing can be used almost everywhere...

Sorry if I was confusing you. What's the purpose of this PR if all links are actually clickable and can open in your default browser? Like in a console you can click the link and it will use your default browser. I'm just confused on what you mean. Do you mean like if you run the code with that feature enabled it will immediately open a new window with that link?

Yeah, that's what I meant.
Sorry, I wasn't able to explain things properly!

It is workable on if you want still.
On Sat, Oct 1, 2022 at 8:23 PM Chinmay @.***> wrote:

Closed #51 https://github.com/ArjunSharda/Searchor/issues/51 as not
planned.
—
Reply to this email directly, view it on GitHub
https://github.com/ArjunSharda/Searchor/issues/51#event-7501284214, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ASQ3JQRSN54OATH7MPEPPHDWBDPY7ANCNFSM6AAAAAAQZ3AMRQ
.
You are receiving this because you commented.Message ID:
@.***>

Sure!

This feature request might take some time though. Just a notice

Yeah, no problems!


Build Immutable Image: Not possible to use Azure Service Subscribtion when using 'user provided' Packer template

It is currently not possible to use a service endpoint when specifying a custom template. That's sad because I have my own template in the repo but still want to run and deploy it on Azure.

@riezebosch - can you please elaborate, "service endpoint when specifying a custom template"? are you referring to a task or template?

I want to use the 'packer build' task to build an image using my own packer template. But I also want to use the Packer Azure Builder. But instead of providing the credentials on the arguments (service principal and client secret) I want to use a Service Endpoint. That combination is currently not possible.
(see also: https://github.com/MicrosoftDocs/vsts-docs/issues/1258#issuecomment-403878078)

Created the tasks myself: https://marketplace.visualstudio.com/items?itemName=riezebosch.Packer

I would let @azooinmyluggage comment on this. However, one complexity I can see is how does task map service endpoint details to custom template's variables? Task does not know which variables are defined in custom template.

Hi @riezebosch
This has been in our backlog for sometime and there is a scenario where it can be used in one of internal requirements. Is there any possibility of you contributing to our task? Having a single task will help everyone. I can work with you on that.

@bishal-pdMSFT For the time being I simply use client_id, client_secret, subscription_id and tenant_id for that because that maps to the field names that are used by the azure-arm provider. If people want to deviate we can introduce input parameters for custom variable names but I dislike the added complexity compared to the added value of that. Another possible solution would be updating the json and simply setting the value of the fields in the directly.
@azooinmyluggage I would love to but I have my concerns about the current vision of the task. Your task tries to abstract the packer details away from the novice whereas my tasks are a mere wrapper around the basic functionality while providing Azure integration. I'm not sure if these two can be combined in a nice way. Maybe you can check if the internal requirements are met with the current implementation of my tasks?


Control Net Reference Only, cannot save pics

I use your updated version with control net reference only, but the picture is not saved in my folder

@timmyhk852
Neither of the two problems you reported could be reproduced in my environment.
Can you give me more details about the operations you performed, settings, etc.? Also, if you are getting errors in the console, please let me know that as well.

same here, can not save img 2 img pics.
Error completing request
Arguments: ('{"prompt": "danae \\(character\\),1girl, best quality, masterpiece, illustration, an extremely delicate and beautiful, extremely detailed ,CG ,unity ,8k wallpaper, (realistic, photo-realistic:1.37),Amazing, finely detail, lora:Danae28_multires-000005:1", "all_prompts": ["danae \\(character\\),1girl, best quality, masterpiece, illustration, an extremely delicate and beautiful, extremely detailed ,CG ,unity ,8k wallpaper, (realistic, photo-realistic:1.37),Amazing, finely detail, lora:Danae28_multires-000005:1"], "negative_prompt": "(worst quality:2), (low quality:2), (normal quality:2), lowres, ((monochrome)), ((grayscale)),paintings, sketches, skin blemishes, bad anatomy,tilted head, multiple girls,bad hands, text, error, missing fingers,extra digit, fewer digits, blurry,bad feet,poorly drawn hands,poorly drawn face,mutation,deformed,jpeg artifacts,signature,watermark,extra fingers,extra arms,extra legs,malformed limbs,fused fingers,too many fingers,cross-eyed,mutated hands,bad body,bad proportions,gross, ng_deepnegative_v1_75t", "all_negative_prompts": ["(worst quality:2), (low quality:2), (normal quality:2), lowres, ((monochrome)), ((grayscale)),paintings, sketches, skin blemishes, bad anatomy,tilted head, multiple girls,bad hands, text, error, missing fingers,extra digit, fewer digits, blurry,bad feet,poorly drawn hands,poorly drawn face,mutation,deformed,jpeg artifacts,signature,watermark,extra fingers,extra arms,extra legs,malformed limbs,fused fingers,too many fingers,cross-eyed,mutated hands,bad body,bad proportions,gross, ng_deepnegative_v1_75t"], "seed":<PHONE_NUMBER>, "all_seeds": [2466413225], "subseed":<PHONE_NUMBER>, "all_subseeds": [1687289444], "subseed_strength": 0, "width": 1080, "height": 1354, "sampler_name": "DPM++ SDE Karras", "cfg_scale": 7, "steps": 20, "batch_size": 1, "restore_faces": false, "face_restoration_model": null, "sd_model_hash": "bbf07e3a1c", "seed_resize_from_w": 0, "seed_resize_from_h": 0, "denoising_strength": 0.4, "extra_generation_params": {}, "index_of_first_image": 0, "infotexts": ["danae \\(character\\),1girl, best quality, masterpiece, illustration, an extremely delicate and beautiful, extremely detailed ,CG ,unity ,8k wallpaper, (realistic, photo-realistic:1.37),Amazing, finely detail, lora:Danae28_multires-000005:1\nNegative prompt: (worst quality:2), (low quality:2), (normal quality:2), lowres, ((monochrome)), ((grayscale)),paintings, sketches, skin blemishes, bad anatomy,tilted head, multiple girls,bad hands, text, error, missing fingers,extra digit, fewer digits, blurry,bad feet,poorly drawn hands,poorly drawn face,mutation,deformed,jpeg artifacts,signature,watermark,extra fingers,extra arms,extra legs,malformed limbs,fused fingers,too many fingers,cross-eyed,mutated hands,bad body,bad proportions,gross, ng_deepnegative_v1_75t\nSteps: 20, Sampler: DPM++ SDE Karras, CFG scale: 7, Seed:<PHONE_NUMBER>, Size: 1080x1354, Model hash: bbf07e3a1c, Model: basil mix, Denoising strength: 0.4, ENSD: 31337"], "styles": [], "job_timestamp": "20230521154125", "clip_skip": 1, "is_using_inpainting_conditioning": false}', [{'name': 'C:\Users\Werran\AppData\Local\Temp\tmp3_ble2rd.png', 'data': 'http://<IP_ADDRESS>:7860/file=C:\Users\Werran\AppData\Local\Temp\tmp3_ble2rd.png', 'is_file': True}, {'name': 'C:\Users\Werran\AppData\Local\Temp\tmpe0ca68kg.png', 'data': 'http://<IP_ADDRESS>:7860/file=C:\Users\Werran\AppData\Local\Temp\tmpe0ca68kg.png', 'is_file': True}], False, 1) {}
Traceback (most recent call last):
File "C:\novelai-webui-aki-v3\modules\call_queue.py", line 57, in f
res = list(func(*args, **kwargs))
File "C:\novelai-webui-aki-v3\modules\ui_common.py", line 73, in save_files
fullfn, txt_fullfn = modules.images.save_image(image, path, "", seed=p.all_seeds[i], prompt=p.all_prompts[i], extension=extension, info=p.infotexts[image_index], grid=is_grid, p=p, save_to_dirs=save_to_dirs)
IndexError: list index out of range

@werran2
Thanks for the info :heavy_heart_exclamation:
You have helped me identify the problem.
I have fixed the problem, please try the latest version.